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