Ticket Hash: | e39d032577df6942f4a91ad7159076fad7710e2a | |||
Title: | Assertion fault on a query containing "x IN (?)" | |||
Status: | Fixed | Type: | Code_Defect | |
Severity: | Important | Priority: | Immediate | |
Subsystem: | Unknown | Resolution: | Fixed | |
Last Modified: | 2014-03-20 13:31:59 | |||
Version Found In: | 3.8.4.1 | |||
User Comments: | ||||
drh added on 2014-03-20 11:52:02:
The following SQL generates an assertion fault: CREATE TABLE t1(a,b); CREATE INDEX t1ab ON t1(b,a); SELECT * FROM t1 WHERE a=? AND b IN (?); The problem appears to have been introduced by the NGQP cut-over on 2013-06-26 (check-in [0fe31f60ca] for version 3.8.0). drh added on 2014-03-20 13:31:59: The failing assert() statement is incorrect. So compiling without -DSQLITE_DEBUG and thus omitting all assert() statements is an easy work-around. This problem only arises in cases where there is a multi-column index and the earlier column is constrained by "x IN (?1)" and the later column is constrained by "y=?2". The fix on trunk is to change the parser so that when the right-hand side of IN is a single expression, the IN operator is converted into ==. This accomplishes the same thing, and it results in tighter VDBE code in the corner-case of a single value on the RHS of IN. Since after the change above, all IN operators have two or more elements on their RHS, the assert() statement is now correct and is retained. |