Include the SQL grammar

[Hywan]

Please, see K-Phoen/php-sql-parser#1.

Thoughts?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[Metalaka]

It could be a really good base to build tests.

But, Do we need a full grammar ?
I seen at least InsertQuery who are missing in this light grammar.

[Hywan]

DML would be great for testing, exactly. Either to validate queries build with Hoa\Database\Query or to generate queries (I don't know how it could be useful yet). Maybe the whole DML (SQL2) is not that difficult. Thoughts?

[Ocramius]

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 :-\

[Hywan]

Is it possible to first normalize vendor-SQL to standard-SQL and then apply the grammar?

[Ocramius]

@Hywan don't think so: it's not a 1:1 transformation anyway

[Ocramius]

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).

[billschaller]

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.