On Mon, Mar 26, 2012 at 9:42 PM, Jay A. Kreibich <j...@kreibi.ch> wrote: > On Tue, Mar 27, 2012 at 03:30:03AM +0100, Simon Slavin scratched on the wall: > Not do drag things out, but how would you "handle" a NaN? If someone > writes a signaling-NaN into the database, the DB will start to throw > floating point exceptions, terminating the host process, with almost > any calculation. Is that really something anyone would consider > "correct" behavior? Sounds more like a great attack vector to me.
To me a singaling NaN in a numeric expression in a SQL statement should yield a SQL exception like SELECT RAISE(FAIL, ...) would (though SELECT statements can't yield failure like that in SQLite3, right?). While signaling NaNs should be converted to quiet NaNs on INSERT/UPDATE. Obviously a singaling NaN could not be stored at all, so the conversion would have to be explicit (or implicit via a PRAGMA) because otherwise the statement must fail... Expressions that consist only of a literal NaN should always yield a quiet NaN, otherwise what would be the point? > In the sense that SQLite recognizes NaNs as error conditions and does > something other than allow the application to terminate, SQLite > *does* "handle" them-- by converting them to a data type SQL already > knows and understands-- and has extremely similar concepts and behaviors. Right, and I think that's useful enough, IMO (except for the mapping back to 0.0 in the C API). Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
