Thomas, I do understand your point of view. However, our intent is to use the AST and custom TableEngine to host in-memory tables without data in them - transient tables/views.
The larger use case requires many other parts that are not H2. Our goal was to use H2 for its great, functional database interface, but the data and logic would be elsewhere. I hope you understand why we are unable to contribute that back to H2 code. I believe that making the AST available/visible would allow some people to use H2 as a "kernel" in certain products. Just like the TableEngine API, if you were to accept this patch, given time, more people would be able to add value/contribute to the core if it is "open" and not an internal API. Other people who need this or built this using Derby or hand built. IMO H2 would've been a cleaner, lighter weight, overall nicer thing to embed - if it were possible: - https://github.com/akiban/sql-parser - http://apache-database.10148.n7.nabble.com/SQL-Parser-Code-in-Apache-Derby-Source-Code-td105458.html - http://rickosborne.org/blog/2010/02/derby-svn-coldfusion-sql-parser/ - https://www.google.com/search?q=derby+sql+parser Ashwin. I don't currently see the use case. Why would you want to manipulate the > AST _outside_ of the database? It sounds like you want to add more features > to the database, but don't want to actually contribute them to the database > itself. That sounds wrong. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/groups/opt_out.
