I've looked at the proposed changes for SQLite V3, and, whilst it all looks reasonable, it does absolutely nothing for me...

The things I'd like would be more at the 'lower' levels of the database.

I'd like to see the query engine be able to use multiple indices if appropriate, rather than just one as it can currently do.
(It might be possible then to extend this to a simple query optimiser or automatic index generation etc at a later stage - possibly as a plug-in-able system based on the 'explain' output of the parser)


I'd also like to see the facility for writing our own locking system to be used by SQLite.

For instance, SQLite could have callbacks for 'table locks', 'row locks', 'page locks' or whatever. If the callback isn't implemented in the application they could equate to file locks as they do now, but having the callbacks would allow the application to put a file lock on the database to stop other programs interfering, then implement its own table/row/page lock as appropriate if it would help. This would help concurrency within a single (multithreaded) application or server, whilst still allowing the current system for simple usage.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to