Any examples of virtual tables that use idxInfo->idxStr?
For it's described usage (an opaque pointer for conveying information between xBestIndex() and xFilter()), having idxStr be a char * rather than void * would seem to make things awkward in the general case. What did the designer of the interface have in mind?
idxStr does need to be a string. SQLite might make a copy of idxStr (to become the 4th parameter to the OP_VFilter opcode in the byte-code engine) and when doing so, it copies the string through the first 0x00 character.
Where in the documentation does it say that idxStr can be a pointer to arbitrary data? That sounds like something that needs to be fixed.
To answer the question posed in the title - the built-in R-Tree virtual table uses idxStr.
Section "2.3.3 Outputs" here says, "The information in idxNum and idxStr is arbitrary as far as the SQLite core is concerned. The SQLite core just copies the information through to the xFilter method. Any desired meaning can be assigned to idxNum and idxStr as long as xBestIndex and xFilter agree on what that meaning is."
I suspect Mr. Jones has interpreted that language to be a meaningless variation on the truly opaque, void-pointer-referent theme seen in other SQLite interfaces.
Perhaps the fragment "core just copies the information" needs to explain that the NUL-termination convention must be respected.
Yes, that was my mis-reading. "Any desired meaning" doesn't automatically imply 'text' to some people.
FYI: This is now clarified in the doc sources and soon will be in the website docs.
Thanks for the pickup.
(7) By Gunter Hick (gunter_hick) on 2021-05-26 09:17:48 in reply to 2.1 [link] [source]
Is there a specific set of circumstances where SQLite chooses to pass a "text copy" of idxStr to vFilter instead of the verbatim pointer? Seems we have been lucky so far...
A convention that I have used in some programs is for idxStr to contain one character per constraint value passed to xFilter (in the argv array), folowed by the null terminator, so that the filter knows what each argument means.
I looked now and the R-tree extension does something similar, actually.