On 5/4/19 12:36 PM, Manuel Rigger wrote: > Hi everyone, > > Consider the following example: > > CREATE TABLE t1 (c0, c1 REAL, PRIMARY KEY (c1, c0)); > INSERT INTO t1(c1) VALUES (0X7ffffffffffffff);; > SELECT ALL * FROM t1 WHERE c1 = 5.76460752303423e+17; > > I would expect the row to be fetched, which is not the case. > > I confirmed that the real value stored is indeed equal to the constant: > > sqlite> SELECT *, typeof(c1) FROM t1; > |5.76460752303423e+17|real > > This is not only the case when using a literal, but also when querying the > value stored in the row in a sub query. So the following expression also > does not fetch the row: > > SELECT * FROM t1 WHERE c1 IN (SELECT c1 FROM t1); > > It seems that the PRIMARY KEY causes the bug. When it is removed (or one of > the columns), the row is returned as expected. > > Best, > Manuel
5.76460752303423e+17 == 576460752303423000 which is even 0X7ffffffffffffff is odd They can't be the same value! Now, depending on how you convert things, they may be close enough to round to the same value if the calculation ends up being done as a real, but that is down in implementation details (a 'Double' has less than 59 significant bits, so can not express the value 0x7ffffffffffffff) -- Richard Damon _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
