Using LIKE on a BLOB is not the problem. It is the LIKE optimization that is broken, because it requires a BLOB to sort AFTER a text, which is never the case, while the LIKE function compares an expression that may contain wildcards to the raw data, which may be the case.
-----Urspr?ngliche Nachricht----- Von: R.Smith [mailto:rsmith at rsweb.co.za] Gesendet: Freitag, 06. M?rz 2015 14:25 An: sqlite-users at mailinglists.sqlite.org Betreff: Re: [sqlite] Virtual Table BestIndex Bug in system.data.sqlite/sqlite with 'like' On 2015-03-06 03:19 PM, Richard Hipp wrote: > Yikes! Actually (1) cannot be determined for normal (non-virtual) > tables either because the value could be a BLOB even if the column > affinity is TEXT. And so the current LIKE optimization is not valid > *ever*. See ticket https://www.sqlite.org/src/tktview/05f43be8fdda9f I > don't yet know how we will fix this... True, but who uses LIKE on a BLOB? Any such usage has to be by accident - though granted, this can happen. Maybe a simple documentation note stating that LIKE operator on BLOB values will have undefined results? _______________________________________________ sqlite-users mailing list sqlite-users at mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick Software Engineer Scientific Games International GmbH FN 157284 a, HG Wien Klitschgasse 2-4, A-1130 Vienna, Austria Tel: +43 1 80100 0 E-Mail: hick at scigames.at This communication (including any attachments) is intended for the use of the intended recipient(s) only and may contain information that is confidential, privileged or legally protected. Any unauthorized use or dissemination of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by return e-mail message and delete all copies of the original communication. Thank you for your cooperation.
