Thanks a lot for the fast answer & fix. -jens
Am 20.03.2014 um 14:41 schrieb Richard Hipp <d...@sqlite.org>: > 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
