Hi,
I'm loading some data using PgSqlLoader. Because of eventual floating point data loss and efficiency, I prefer to use binary mode (cf. my previous posts here).
What's troubling me now are NULL values. When using text mode, loading data with NULLs in it works fine. Simply changing Mode to PgSqlLoaderMode.Binary causes a NullReferenceException to be thrown when NextRow is called.
Might this be a bug?
PgSqlLoader and null values
We have reproduced the NRE in the PgSqlLoaderMode.Binary mode when inserting DBNull.Value into database. We will investigate the issue and notify you about the results as soon as possible.
Could you please point the threads where the eventual floating point data loss and efficiency problems in the PgSqlLoaderMode.Text mode were not resolved?
Could you please point the threads where the eventual floating point data loss and efficiency problems in the PgSqlLoaderMode.Text mode were not resolved?
Hi,
The referenced thread where the issue of floating point data loss in text mode was raised is this one http://www.devart.com/forums/viewtopic.php?t=17179.
Note that this possibility of data loss is not raised by your software alone. It is PostgreSQL who will receive the text data and parse the floating point values in it.
Representing a floating point number in decimal and then decoding it to binary mode is hard to guarantee. The C standard makes no numeric accuracy requirements on its I/O functions, and IEEE is unaware of I/O. So, even if you use 16 decimal digits, it's hard to guarantee that PgSql (by coincidence written in C) will parse them accurately, let alone having all special cases (+/-0, +/-inf, 4 flavours of NaN and denormals) correctly handled.
I wouldn't put my hands on the fire for it.
So, in some cases, when you care very much of your 13th and 14th digits, and the sign of your infinities, maybe its better not to put it in decimal.
I worked around the issue. In this application I have the luck that when I want to load a bunch of data, when some columns are NULL, they are NULL on all rows. Thankfully.
The referenced thread where the issue of floating point data loss in text mode was raised is this one http://www.devart.com/forums/viewtopic.php?t=17179.
Note that this possibility of data loss is not raised by your software alone. It is PostgreSQL who will receive the text data and parse the floating point values in it.
Representing a floating point number in decimal and then decoding it to binary mode is hard to guarantee. The C standard makes no numeric accuracy requirements on its I/O functions, and IEEE is unaware of I/O. So, even if you use 16 decimal digits, it's hard to guarantee that PgSql (by coincidence written in C) will parse them accurately, let alone having all special cases (+/-0, +/-inf, 4 flavours of NaN and denormals) correctly handled.
I wouldn't put my hands on the fire for it.
So, in some cases, when you care very much of your 13th and 14th digits, and the sign of your infinities, maybe its better not to put it in decimal.
I worked around the issue. In this application I have the luck that when I want to load a bunch of data, when some columns are NULL, they are NULL on all rows. Thankfully.
New build of dotConnect for PostgreSQL 4.95.170 is available for download now!
It can be downloaded from http://www.devart.com/dotconnect/postgr ... nload.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=19070 .
It can be downloaded from http://www.devart.com/dotconnect/postgr ... nload.html (trial version) or from Registered Users' Area (for users with valid subscription only).
For more information, please refer to http://www.devart.com/forums/viewtopic.php?t=19070 .