On 2014/03/05 10:41, Dominique Devienne wrote:
On Tue, Mar 4, 2014 at 9:41 PM, Elefterios Stamatogiannakis
One thing that IMHO long term might improve the situation would be if
SQLite's own "native" tables would use the same Virtual Table API,//...
...//Of course, the above is a "naive" abstract reflection which ignores
the realities of VDBE, so it may sound rubbish to actual SQLite
developers. Apologies for that. --DD
I don't think it is rubbish at all, but maybe idealistic. The biggest problem I can see from making API's pov is that you can at
any time alter, update, change the way SQLIte (or any other API) works with the base check that the input values produce the same
(or maybe more-correct) results. Once you let the VT use the same API, any change is a potential change to how other people's
programmed interfaces need to talk to - or get data from - the SQLite engine. This cannot simply change on a whim, so the levels of
separation remain needed.
That said, I'm all for making a more efficient VT API, but it would probably need to be "new" functionality since I cannot see how
the existing interface could implement any of the mentioned enhancements without breaking existing behaviour. The OP's xNextRow
suggestion seems a good idea, but opens up a whole can of what-ifs which other posters have alluded to, but something to that effect
might be worthwhile if the efficiency bonus is significant.
Cheers
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
