At 03:41 22/12/2006, you wrote:
There has been discussion about extending Sqlite to have more functions, but the risk is creating Sqlite-Bloat and losing the most endearing feature of the product, its light weight and simplicity.

Here is an interesting and thought provoking discussion on the general subject. A good case is made for more extensive use of a data-specific language, specifically PL/SQL.

It would be a major restructure of Sqlite, but it would be intriguing to see the VDBE virtual machine extended to have the features to execute a subset of PL/SQL and to have the Sqlite compiler also compile the PL/SQL dialect into virtual machine code. Then executables could be stored in the database, functions could be added and with ingenious design the footprint could be smaller by splitting off the compiler and having as many internal functions as possible realized in the dense virtual machine code. It is not a new concept, having been the principle behind Java and many other similar projects, but it is one where the ideal solution is yet to emerge.

By using an efficient virtual machine with a dense target code performance should be good and be frugal on resources on embedded devices. The virtual machine code is processor independent, making distribution of modules very straight forward.

http://www.viacognis.com/devicesql/ArticleDataCentricSoftware.pdf

Sounds very interesting, and after reading it i think there no embedded database like sqlite that has PL/SQL, only Oracle and similar sizes. I think it's a very good idea and i can help in develop it, but don't know much about the VDBE code. I think adding control structures to SQLite SQL will not make it heavier, perhaps 20-40 Kb of optional code in parser/vdbe. Optimization will be another headache

But the question is always the same, Who?. Read this message from Dr. Richard Hipp on 23/10/2006 with subject "Re: [sqlite] Extra functions - New Project?"



-----------------------------------------------------------------------------------------
Useful Acronymous : FAQ = Frequently 'Answered' Questions

-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to