Ticket Hash: | 93fb9f89d6a69dc3d8e627197d21a15dcb4eaaf7 | ||
Title: | Index causes incorrect WHERE clause evaluation | ||
Status: | Fixed | Type: | Code_Defect |
Severity: | Critical | Priority: | Immediate |
Subsystem: | Code_Generator | Resolution: | Fixed |
Last Modified: |
2009-08-19 15:21:05 15.87 years ago |
Created: |
2009-08-13 16:43:29 15.89 years ago |
Version Found In: | 3.6.17 |
Description: | ||||
Consider the following SQL:
CREATE TABLE t1(x,y); INSERT INTO t1 VALUES(1,2); INSERT INTO t1 VALUES(2,7); INSERT INTO t1 VALUES(3,4); CREATE TABLE t2(a, b TEXT); CREATE INDEX t2b ON t2(b); INSERT INTO t2 VALUES(1,2); INSERT INTO t2 VALUES(5,6); SELECT *, y=b FROM t1, t2 WHERE y=b; In the final SELECT statement, the last column ("y=b") shows zero (false) in the output. Clearly this must be wrong because if "y=b" is false, the WHERE clause should have prevented the row from being returned. The problem goes away if the index on t2(b) is removed. It appears that the query planner is using the t2b index to resolve the WHERE clause even though the t1.y and t2.b columns have incompatible type affinities. drh added on 2009-08-19 15:21:05: The fix for the problem is check-in [e72186f2d68d28c2e0c32894f9adb28c155b5f63]. Test cases for this fix are in the test/whereB.test test script. |