On 1/19/15, RSmith <rsm...@rsweb.co.za> wrote:
> Might this not be a "reverse_unordered_selects" pragma or compile option
> going wrong, or at least the code making it work getting
> somehow hooked in the new versions for this query?
>
It looks like a bug. If you update to the latest trunk check-in and set:
.testctrl never_corrupt 1
prior to running the test query, you get an assertion fault.
That new dot-command invokes
sqlite3_test_control(SQLITE_TESTCTRL_NEVER_CORRUPT, 1) which tells
SQLite that no database it deals with will ever be corrupt. And this,
in turn, enables some additional assert() statements which are
normally turned off. One of those new asserts finds the incorrect
logic.
We are working on a simple test case and a fix now. It is a very
complex problem. In particular, the sample query works fine as long
as the number of columns in the result set is not exactly 60. Adding
or removing a single column of result gives the correct answer.
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
