|13:57||• Fixed ticket [05f43be8]: Incorrect use of index with LIKE operators when the LHS is a blob plus 5 other changes (artifact: c140b281 user: drh)|
|13:56||Fix the LIKE optimization so that it finds BLOB entries in addition to text entries. Ticket [05f43be8fdda9f]. (check-in: 74cb0b03 user: drh tags: trunk)|
|20:49||Test cases added. Comments fixed. Proposed solution for ticket [05f43be8fdda9fbd9]. (check-in: 6b993bd5 user: drh tags: like-opt-fix)|
|16:45||The LIKE optimization must be applied twice, once for strings and a second time for BLOBs. Ticket [05f43be8fdda9f]. This check-in is a proof-of-concept of how that might be done. (check-in: 5757e803 user: drh tags: like-opt-fix)|
|13:14||• New ticket [05f43be8] Incorrect use of index with LIKE operators when the LHS is a blob. (artifact: 9a374a0d user: drh)|
|Title:||Incorrect use of index with LIKE operators when the LHS is a blob|
|Last Modified:||2015-03-07 13:57:01|
|Version Found In:||220.127.116.11|
drh added on 2015-03-06 13:14:40:
In the following SQL, the first query returns no rows whereas the second query returns one row. Both queries should operate as the second.
CREATE TABLE t1(x TEXT UNIQUE COLLATE nocase); INSERT INTO t1(x) VALUES(x'616263'); SELECT 'query-1', x FROM t1 WHERE x LIKE 'a%'; SELECT 'query-2', x FROM t1 WHERE +x LIKE 'a%';
This problem appears to have been introduced on 2005-08-28 (9.5 years ago) by check-in [ef84ff795c85e9d2]. And yet the problem has never been observed in the wild. The problem was discovered by the SQLite developers while reasoning about the validity of the LIKE optimization.