Since the consortium members are prominently listed on those pages, I hope it is not inappropriate if my comments refer to a couple of them. Nothing disparaging.
As I am in the process of discovering (and so subject to revision/correction), there are a number of capabilities in SQLite that are disabled or not enabled in consortium member Adobe's implementation. LoadableExtensions don't seem to be available, and PRAGMA is not. Adobe has good reasons for this, I'm sure, but these limitations leave my application rather high and dry on two counts: 1. Without PRAGMA, I cannot set the case-sensitivity of the LIKE operator and so cannot get use of index optimization on queries like this: ... where myTextColumnUsingDefaultBinaryCollation like 'foo%' The alternative, NOCASE collation, also does not get me out of the woods. For some reason in Adobe (and in Mozilla) the index is not used on LIKE clauses when the column in question has NOCASE collation, though SQLite3.EXE does use the index in its query plan on the same query. These consortium members might be overriding the LIKE function or compiling statements not with _V2 or doing something else that prevents the optimization. I don't know. This has a major impact on performance. Queries that take < 100ms in SQLite3.EXE take 40-50 seconds in Adobe (and Mozilla) because of the full-table-scan. 2. In Adobe, one is not able to load a user-defined function as an extension. I need a *raw* codepoint-by-codepoint reversal of a text string, which makes no attempt to distinguish between Unicode combining characters and base-characters, similar to what can be done in Oracle and SQLServer. I have some ideas on how these two limiting features of Adobe's implementation of SQLite might be addressed. I don't know how feasible they might be given the existing codebase because I am not a C coder. INDEX-OPTIMIZATION WITH LIKE A. Make the existing LIKE operator able to recognize the column COLLATION and adapt its case-sensitivity to that COLLATION. B. Create another LIKE that is *always* case-sensitive. RAWLIKE or SLIKE or whatever. It does a simple codepoint-by-codepoint test and doesn't have any special intelligence for ASCII/LATIN. RAW STRING REVERSAL This is a simple function and the other major players have it. It seems to me that it should be easy to implement. Concerns about combining characters and base characters and higher order Unicode intelligence could be saved for a UREVERSE() function, one which preserves Unicode composed characters. Thanks for considering. Regards Tim Romano D. Richard Hipp wrote: > Last minute comments on the pending release of SQLite 3.6.21 are > welcomed. Visit > > http://www.sqlite.org/draft/index.html > http://www.sqlite.org/draft/releaselog/3_6_21.html > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
