On Thu, 13 Jun 2019 at 01:28, Richard Hipp <d...@sqlite.org> wrote:
> On 6/12/19, Jonathan Brandmeyer <jbrandme...@planetiq.com> wrote:
> > IMO, when acting as a storage engine, SQLite should be good to the last
> > bit.
>
> That is already the case, and has been for 17 years. The question at
> hand is what should SQLite do when the application asks it to convert
> a -0.0 value into text. It is only the binary-to-text conversion
> routine that is at question here. If you are reading back your
> database content using sqlite3_column_double(), you get back
> bit-for-bit exactly what you put in.
>
Strictly speaking this isn't true - if using the C interface to pass in
-0.0 it used to get returned as 0.0 due to the optimization where
"SQLite converts
integer floating point values to actual integers for storage (because that
takes up less space on disk) and then converts back to double upon
retrieval. That round-trip would change -0.0 into +0.0." (2015) That may
have changed in recent years as I haven't explicitly tested it once I
worked around this behaviour by storing some double values as BLOBs.
Similarly passing in a bit representation of NaNs will not get you
bit-for-bit exactly what you put in, as SQLite discards it on the return
trip (also from 2015, though this code is still present so I assume the
behaviour is the same):
sqlite3_bind_double calls sqlite3VdbeMemSetDouble which has a specific
check against NaN. My assumption is that this is what results in NaNs not
round tripping and instead coming back out as SQLITE_NULL:
SQLITE_PRIVATE void sqlite3VdbeMemSetDouble(Mem *pMem, double val){
sqlite3VdbeMemSetNull(pMem);
if( !sqlite3IsNaN(val) ){
pMem->u.r = val;
pMem->flags = MEM_Real;
}
}
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
