On Fri, 24 Mar 2017 11:03:10 -0400 Richard Hipp <d...@sqlite.org> wrote:
> On 3/24/17, James K. Lowden <jklow...@schemamania.org> wrote: > > > > We know SQLite parses SQL to produce byte-code for its virtual > > machine. And we know that's an abstract syntax tree. And we know > > trees can be represented as tables. Therefore we know the AST > > could be returned as tables. That was my suggestion. > > The AST used by SQLite changes. Frequently. If we provide an > interface that returns the AST as a (virtual) table, that would make > the AST an interface, and prevent us from enhancing it in the future, > for new features or performance improvements. I fully appreciate that concern, and the problem of documentation and clarity. I probably shouldn't have referred specifically to the AST. The output I think SQLite users could benefit from isn't the emitted bytecode. It's the parse tree: the affected objects and the operations on them. If that tree were returned as a table or tables, the user could query it to discover, say, how many tables are used, or how many times a particular table is used. Before dropping a table, they could interrogate the results for any views (and perhaps queries) to make sure the table is no longer referenced. Or, as this thread started, it could be used (in application code) to drop dependent views when a table is dropped. I don't see how the parse tree would be volatile or hard to understand. Naturally, it's subject to the same cost/benefit analysis as any other feature. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
