Alek Paunov <a...@declera.com> writes: > So maybe it's worth to give it a try ... Is there someone else, which > is interested to work on VDBE dump/load to assembler representation? > Once these base tools are available, maybe other people would reuse > bytecode instrumentation for other purposes also ;-)
I don't have time to work on this at the moment, but here is my input: I think the improved update functionality is important, and presumably easily supported by sqlite's existing virtual machine. I disagree that databases should not be used to perform calculations. Actually SQL can be very concise for expressing calculations, and in fact the database engine may be able to optimise the query better than what a client could achieve by issuing separate SELECT and UPDATE queries. Also, by making use of views, triggers and stored procedures, the database can provide a useful abstraction layer. Sqlite already does this very well with views and triggers, but lacks parameterised view/stored procedure functionality. Another reason to use the database for doing calculations (including iterative or recursive ones) is that you can use the native SQL data representation, including things like NULL support which are often missing from other languages, plus it can be faster because of not needing to convert types between sqlite's internal representation and another language representation. It has been noted that sqlite already has a turing-complete virtual machine, so why not provide the front-end facilities to make full use of it? I expect it wouldn't take much effort to implement a procedural language and/or recursive joins based on the current virtual machine. I realise this is a 'lite' database, but it seems as if the heavy lifting has already been done. In researching this previously I noted an existing effort at adding a procedural language to sqlite: 1. http://www.sqliteconcepts.org/PL_index.html This effort looks quite good although I think it needs some refinement. It adds the ability to execute procedural code immediately or in a stored procedure. Both would be exceptionally useful additions to sqlite, even if available only as an optional module. I would suggest using PostgreSQL as a reference for implementing a procedural language, since it has a robust procedural language implementation, and I and I suspect others already use both postgres and sqlite. I realise I have gone off in a somewhat different direction from the VDBE dump/load capability. I think this would be a useful feature as well, but more useful for experimenting with the development of new functionality, such as compiling new language constructs. Probably both could could be done at once. -- Mario Becroft <m...@becroft.co.nz> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
