Changing the 2 "15g" entries in sqlite3.c to "16g" corrects this problem. 15 digits is all that is guaranteed but the vast majority of 16-digit values are representable.
Is this a valid solution? Or are there other side effects? Before change: sqlite> create table t (a float); sqlite> insert into t values(1125899906842624); sqlite> select * from t; 1.12589990684262e+15 sqlite> select a = cast(a as text) as float from t; 0 After change: sqlite> create table t(a float); insert into t values(1125899906842624); sqlite> select * from t; 1125899906842624.0 sqlite> select a = cast(a as text) as float from t; 1 Michael D. Black Senior Scientist NG Information Systems Advanced Analytics Directorate From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Wiktor Adamski [bardzotajneko...@interia.pl] Sent: Wednesday, October 05, 2011 9:34 AM To: sqlite-users@sqlite.org Subject: EXT :[sqlite] Big FLOAT bug SQLite version 3.7.8 2011-09-19 14:49:19 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table t(a float); sqlite> insert into t values(1125899906842624); sqlite> select a = cast(cast(a as text) as float) from t; 0 Yes, I know - 16 digits. But representable 16 digits. .dump also will export only 15 digits ant without any explicit casts precision will be lost after importing. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
