Closed gadumitrachioaiei closed 10 years ago
Hi gadumitrachioaiei, Our initial intent was to only support the most common MySQL constructs. However, we are revisiting that decision. So, it's possible that we may decide to go all the way. Until then, you'll have to rewrite the queries to a syntax that we support.
If you're trying to reuse the parser for something else, you should be able to fork and add the necessary constructs. Just to contrast, our sql.y has 990 lines, while https://github.com/twitter/mysql/blob/master/sql/sql_yacc.yy has 14K lines :). The grammar we use has been heuristically simplified to cover a pretty wide range of what MySQL allows, while still remaining intuitively readable.
PS: Among your suggested constructs, you could easily convince me to extend our grammar to support ANY (and SOME). The table alias for DMLs is also something that's relatively easy to add. However, the JOIN on DMLs is something we probably can't support easily due to other dependencies with vitess.
@sougou Not allowing joins has been a (great) design goal of of vitess, AFAIR. Is this design goal still valid?
I'm not sure why you think joins are bad. Can you clarify?
Thanks for the explanations. I had the intention of using vitess only for parsing sql queries.
I have tried the sqlparser library and I get parsing errors on a few sql queries. Some examples: DELETE FROM term_hierarchy AS th WHERE th.parent = 1015 Error at position 30: as
SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2) Error at position 41: select
DELETE FROM t1, t2 USING t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.id=t2.id AND t2.id=t3.id Error at position 16: ,