On Sun, Apr 6, 2014 at 10:23 PM, Dominique Devienne <ddevie...@gmail.com> wrote:
> > If the answer to either question above is true, then a specialized > vtable would be both more convenient and faster, no? > Hmm... If logical peculiarity of vtable approach (when where-constrained queries might be larger than full-scan one) is acceptable by sqlite (mentioned in my other post), then where expression might serve as parameters so a possible hybrid might be possible (also inspired by the recent discussion of creating user functions on the fly). For example, a virtual table that accepts a Select statement might look like CREATE VIRTUAL TABLE vcommalist USING QueryVirtualizer('WITH RECURSIVE .... :commalist .... ') And the actual query using it might look like SELECT * FROM vcommalist WHERE commalist='1,2,3,4,5' This one served more like shortcut, but probably a more broad version is possible when the parameter to virtual table is a print formatted string so one can dynamically customize parameters general parameters can't, i.e., table names, output column names etc. Multiply parameters would be great, but with current state of things the implementation still should use some kind of workaround to ensure correct results so should always return huge estimatedCost in xBestIndex if the constrained arrived doesn't contain at least one required parameter (WHERE clause lacks one) and low one if all parameters are provided. I think that sqlite might as well interpret estimatedCost equal to -1 as a ban to use this index. Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users