Sorry, I should have anticipated that we get slightly different values. Shouldn't the query "SELECT * FROM t1 WHERE c1 IN (SELECT c1 FROM t1);" return a result though?
Best, Manuel On Sat, May 4, 2019 at 8:17 PM Keith Medcalf <kmedc...@dessus.com> wrote: > > Ooopsie ... that should have been 1e17, and it appears to be fine, except > that: > > SELECT ALL * FROM t1 WHERE c1 = (select c1 from t1); > > does not work ever though the value returned from the subselect should be > exactly the value in the index ... > > A table scan does however work correctly ... > > sqlite> SELECT ALL * FROM t1 not indexed WHERE c1 = (select c1 from t1); > |5.76460752303423e+17 > > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > >-----Original Message----- > >From: sqlite-users [mailto:sqlite-users- > >boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf > >Sent: Saturday, 4 May, 2019 12:09 > >To: SQLite mailing list > >Subject: Re: [sqlite] Problem with REAL PRIMARY KEY > > > > > >There is, however, something weird: > > > >SQLite version 3.29.0 2019-05-04 17:32:07 > >Enter ".help" for usage hints. > >Connected to a transient in-memory database. > >Use ".open FILENAME" to reopen on a persistent database. > >sqlite> .version > >SQLite 3.29.0 2019-05-04 17:32:07 > >c2e439bccc40825e211bfa9a88e6a251ff066ca7453d4e7cb5eab56ce733alt2 > >zlib version 1.2.11 > >gcc-8.1.0 > >sqlite> CREATE TABLE t1 (c0, c1 REAL, PRIMARY KEY (c1, c0)); > >sqlite> INSERT INTO t1(c1) VALUES (0X7ffffffffffffff);; > >sqlite> SELECT ALL * FROM t1 WHERE c1 = 5.76460752303423e+17; > >sqlite> SELECT ALL * FROM t1 WHERE c1 = (select c1 from t1); > >sqlite> SELECT ALL * FROM t1 WHERE c1 > (select c1 - 1 from t1); > >sqlite> select c1 from t1; > >5.76460752303423e+17 > >sqlite> select c1 - 1 from t1; > >5.76460752303423e+17 > >sqlite> > > > > > >--- > >The fact that there's a Highway to Hell but only a Stairway to Heaven > >says a lot about anticipated traffic volume. > > > > > >>-----Original Message----- > >>From: sqlite-users [mailto:sqlite-users- > >>boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp > >>Sent: Saturday, 4 May, 2019 11:49 > >>To: SQLite mailing list > >>Subject: Re: [sqlite] Problem with REAL PRIMARY KEY > >> > >>On 5/4/19, Manuel Rigger <rigger.man...@gmail.com> 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. > >> > >>But 0x7ffffffffffffff != 5.76460752303423e+17. Try it: > >> > >> SELECT 0x7ffffffffffffff != 5.76460752303423e+17; > >> > >>You should get back 0. > >> > >>The rule of thumb is to never expect the == operator to give a > >>meaningful answer for floating-point numbers. Only use <, <=, >, > >and > >>>=. > >> > >>-- > >>D. Richard Hipp > >>d...@sqlite.org > >>_______________________________________________ > >>sqlite-users mailing list > >>sqlite-users@mailinglists.sqlite.org > >>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > >_______________________________________________ > >sqlite-users mailing list > >sqlite-users@mailinglists.sqlite.org > >http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
