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
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
