On Tue, 26 Jul 2016 16:40:07 -0400 Richard Hipp <d...@sqlite.org> wrote:
> On 7/26/16, John Found <johnfo...@asm32.info> wrote: > > Is it possible to use SQLite, making queries directly in the internal > > virtual machine language, instead of SQL? > > No. Why do you want to do this. The SQL language is the most > compelling feature of SQLite. Why abandon it? > Well, I am assembly programmer and assembly style syntax is much more readable and native for me. I use SQLite for many of my projects and sometimes I wonder whether the internal "assembly kind" of language wouldn't fit better to assembly language writing style than the high level SQL. In addition, I never use dynamically created queries because of security reasons, so all SQL queries in my programs are string constants. This way, preparing them in compile time looks pretty natural. > > > > > Or in another variant, compile the queries in design time, manually optimize > > them (if needed) and then store and call in the program in compiled form? > > Years ago, we did a custom version of SQLite for a start-up in which > the SQL was rendered into byte-code at compile-time and stored in the > database. Then at run-time, the application simply invoked an API > that said essentially "run statement N using the following > parameters". SQLite would then load the byte code out of the database > file, bind the parameters, and run the statement. > > By preparing the SQL to byte-code at compile-time, the whole SQL > parser, query planner, optimizers, and code generator could be omitted > from the build, which saved a lot of code space on the embedded device > where it was to be run. > Yes, the size optimization is something that every assembly programmer likes. :) The Mrs.Todd's principle: "Save enough miles and soon enough you'll save time." > Limitations were severe. The byte code varies according to the > database schema and the specific build of SQLite. So, you could not > change your database schema without recompiling the application. And > your database file was tied to a specific version of the application > and would not work with a different version. Well, yes, this can be serious problem. I expected bytecode to be constant and compatible between versions and only the way queries are compiled to differ. > > All this was all a long time ago. And it was a custom build which was > never ported to the public SQLite source tree. SQLite does not > currently have that capability. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users -- http://fresh.flatassembler.net http://asm32.info John Found <johnfo...@asm32.info> _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
