|15:10||• Fixed ticket [80ba2010]: Bug involving subqueries and the OR optimization plus 2 other changes (artifact: e6007e38 user: drh)|
|18:59||Back out part of the previous change that was not really necessary in order to fix [80ba201079ea60], and which in fact serves no useful purpose. (check-in: fa9eef86 user: drh tags: trunk)|
|18:50||Initialize all constants at the very beginning of a prepared statement. Do not allow constant initialization to occur once control flow has a chance to diverge, to avoid the possibility of having uninitialized registers. Ticket [80ba201079ea60807]. (check-in: c5c53152 user: drh tags: trunk)|
|16:01||• New ticket [80ba2010] Bug involving subqueries and the OR optimization. (artifact: 4cebcddb user: dan)|
|Title:||Bug involving subqueries and the OR optimization|
|Last Modified:||2010-12-07 15:10:31|
|Version Found In:||3.7.3|
SELECT statements can return incorrect results in certain cases where the following are true:
CREATE TABLE t1(a); INSERT INTO t1 VALUES('A'); CREATE INDEX i1 ON t1(a); CREATE TABLE t2(b); INSERT INTO t2 VALUES('B'); CREATE TABLE t3(c); INSERT INTO t3 VALUES('C'); SELECT * FROM t1, t2 WHERE (a='A' AND b='X') OR (a='A' AND EXISTS (SELECT * FROM t3 WHERE c='C'))
The bug causes the query above returns zero rows instead of the expected result - one row.
This bug was discovered in a real application and reported on the mailing list. Bisection reveals that it was introduced on 2009-08-13 by commit [86a06dd049]. It first appeared in release 3.6.18.