-
Notifications
You must be signed in to change notification settings - Fork 13
Include the SQL grammar #24
Comments
It could be a really good base to build tests. But, Do we need a full grammar ? |
DML would be great for testing, exactly. Either to validate queries build with |
Implementing just SQL92 parsing seems feasible: http://savage.net.au/SQL/sql-92.bnf.html Using it... not so much. The problem is that SQL92 is not really supported cross-vendor :-\ |
Is it possible to first normalize vendor-SQL to standard-SQL and then apply the grammar? |
@Hywan don't think so: it's not a 1:1 transformation anyway |
Keeping it SQL92 is feasible, then generating vendor-specific from SQL92, but generating SQL92 from vendor-specific is a huge project (basically becomes a transpiler). |
There are grammars for MySQL, TSQL, PL/SQL, and SQLite available for antlr. Those would be a good starting point for parsing vendor sql into a common semantic representation. It would have to be a subset, because some things, like cursors, are not going to translate. DDL can pretty well be condensed, discarding a lot of vendor fluff. Another thing to consider is in parsing vendor dialects, we can smuggle vendor features in some cases by adding extra information to the 'common' semantic nodes, and then decorating them later when we generate vendor sql. Examples would be CLUSTERED index modifier, or LIMIT. Take a look at SqlAlchemy's dialect system. |
Please, see K-Phoen/php-sql-parser#1.
Thoughts?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: