On Sun, May 18, 2014 at 9:46 PM, James K. Lowden
<jklow...@schemamania.org> wrote:
> I can easily imagine uses for a generalized SQLite parser, one that
> returned an abstract syntax tree. A program might use such a thing for
> all sorts of "server-side" functionality, for example to process a
> string provided to a virtual table function.
I very much wish for that in fact!
Many of our app's UI tables and trees are based on "model" SQL queries
that return the "raw" data, which are then "massaged", "wrapped",
etc... to derive new ("model" or "view") queries, and we've found
several situations where using the raw model queries as an inner query
is inefficient. We do get some info from prepared statements, by
looking at the VDBE bytecode, but ended up asking client code to
provide us a query by "pieces" (separate clauses, sometimes further
broken down) rather than a complete query, to work-around the lack of
AST. Doing our own parsing would likely be brittle and only work for
simpler queries, but really using the true full query AST is what we'd
need for a completely general solution, that is more API-friendly to
client code (they provide just full queries).
Ideally, there'd be two AST "levels":
1) A pure syntactic AST (which does not require a connection);
2) a resolved "semantically-analyzed" AST where all expressions are
resolved to known table.column "bindings" (or bind placeholders).
> But that's a very different sort of project. It wouldn't be easy to do
> in SQLite because AIUI the byte-code program produced by the prepare
> functions is concrete, comprising operations and references to actual
> database objects.
That would be my "resolved" AST. But I'm not sure you can get the
query AST from the VDBE program myself. --DD
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
