Sorry, I missed out my point: SQLite version 3.8.10.2 2015-05-20 18:17:19 Enter ".help" for usage hints. sqlite> CREATE TABLE t(r REAL PRIMARY KEY,t TEXT); sqlite> INSERT INTO t VALUES (21.0,'twenty one point zero'); sqlite> INSERT INTO t VALUES (9.2+7.9+0+1.0+1.3+1.6, 'calculation'); sqlite> SELECT * FROM t WHERE r>10; 21.0|twenty one point zero 21.0|calculation
It is this that worries me. No that both rows are printed as '21.0', but that SQLite did not use slop when checking to see whether the two values were duplicates. I feel that it should have rejected the second INSERT command because of the duplicate key. Obviously an extremely tiny minority of SQLite databases have a UNIQUE KEY on a REAL column. But fixing this may fix other bugs. Simon Slavin.
