Tim,
>But did I say that GLOB uses an index if it has been overloaded? No. I
>wrote that if LIKE has been overloaded, queries that contain LIKE
>won't use
>the index. Typically, GLOB won't have been overridden too just
>because LIKE
>has been overridden: the rationale for overriding the LIKE operator
>does not
>apply equally to GLOB, and it would make little sense to override GLOB
>in a
>manner that vitiates its raison d'être. You are conflating these two
>functions ("... if LIKE/GLOB has been overridden... overloads LIKE/GLOB")
>but in important respects they are dissimilar.
I agree it is possible to overload LIKE and GLOB independantly but I
don't see a practical situation where overloading only one of them
would be desirable.
For instance, if some extension overloads LIKE to support ICU, it would
be logical and consistent to overload GLOB with the same
function. Given that the two entries differ only by a parameter,
enjoying Unicode support in LIKE and not in GLOB (or vice-versa) would
be a bit strange.
Should one have a need to keep the native functions untouched, there is
the easy possibility to call the new versions with new names (e.g.
LIKEU, GLOBU) even if that makes the SQL less standard.
In short: possible yes, likely not much.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
