A practical situation? Lexicographical applications and full-text applications against text corpora require indexed substring searches, including ends-with searches. (The FTS extension is not always a good fit.) I am glad that only the LIKE operator has been overridden in Adobe's version and in the version that ships with the System.Data.SQLite (.NET) adapter; I'd be up the creek if both LIKE and GLOB had been overridden. I like your renaming suggestion but unfortunately that's not an option if the implementors want to make their implementation widely available and support standard syntax. Hence, Adobe and Google et al don't have a LIKEU().
Tim Romano On Wed, Apr 28, 2010 at 10:09 AM, Jean-Christophe Deschamps <j...@q-e-d.org>wrote: > Tim, > > > 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 > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
