The ticket is now closed. Thanks for the bug report. To confirm: The simplest fix is merely to compile without -DSQLITE_DEBUG which will disable assert() statements, as the problem is an incorrect assert(). There is nothing actually wrong with the logic, that we can see. An alternative work-around is to delete or comment-out the offending assert() statement.
The fix on trunk retains the assert(). The assert() is correct as long as the right-hand side of IN operators always have two or more values. In other words, the assert() is correct as long as you never have "x IN (?)" with exactly one element in the right-hand side. On trunk, the parser has been modified to automatically convert IN and NOT IN operators with exactly one element on their right-hand side into == and <> operators. That change makes the assert() correct again, and it results in faster evaluation SQL statements that have an IN or NOT IN operator with just a single RHS element. On Thu, Mar 20, 2014 at 8:27 AM, Richard Hipp <d...@sqlite.org> wrote: > http://www.sqlite.org/src/info/e39d032577 > > It appears that the fix will be to simply remove the assert() statement, > which is incorrect. But it will take some time to verify that this is the > correct fix and add new test cases, etc. > > Your work-around is to simply compile without -DSQLITE_DEBUG (thus > disabling all assert() statements) or delete the assert() that is failing. > > > On Thu, Mar 20, 2014 at 7:26 AM, Jens Miltner <j...@mac.com> wrote: > >> Hi, >> >> I ran into the following problem after updating the SQLite 3.8.4.1: >> >> When executing the following (rather basic) SELECT query in a debug build >> of sqlite3, this will cause an assertion to fire in >> whereLoopAddBtreeIndex() (sqlite3.c, line 13411): >> >> SELECT * FROM t1 WHERE(foo_id=5 AND name IN ('foo')); >> >> The database schema to reproduce is: >> >> CREATE TABLE t1 (id INTEGER PRIMARY KEY, foo_id INTEGER, name >> VARCHAR(36), phone VARCHAR(36)); >> CREATE UNIQUE INDEX t1_udx ON t1(name, foo_id); >> CREATE INDEX t1_idx ON t1 (phone, foo_id); >> >> >> The assertion that fires is the following: >> >> assert( (pNew->wsFlags & WHERE_COLUMN_IN)==0 || iCol<0 ); >> >> >> This is quite annoying, since it will terminate the app when we build our >> app with DEBUG enabled and a similar query is executed. >> >> Can you SQLite folks please have a look into this? >> >> Thanks, >> -jens >> >> >> >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > > -- > D. Richard Hipp > d...@sqlite.org > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
