MySQL support

[jmhodges]

Love this project idea! All of my tools are built on mysql 5.x and it'd be great to have that supported.

[kyleconroy]

There's a high-quality open source MySQL parser included in the vitess project (https://godoc.org/github.com/youtube/vitess/go/vt/sqlparser#BuildParsedQuery). I'll take a look into using that.

[clintberry]

We actually are looking at using this for vitess in particular. Super excited you are at least looking at it.

[mightyguava]

TiDB also has a pretty good standalone MySQL parser worth taking a look at: https://github.com/pingcap/parser

I've been using sqlc in a hobby project and really love it. Would love to see MySQL support so I can use it at work too.

[cmoog]

@kyleconroy
This project is super cool and basically the best solution I've come across for adding type safety and code generation to the data access layer. I'm in the process of adding MySQL support on a fork branch here.
A few things to note:

• much of the generator logic is specific to the pg parser. On my branch, I've attempted to abstract the Go generator logic to be parser-agnostic. To further clean and decouple the components, I think it would be wise to separate gen into its own package.
• how do you envision the user specifying their desired parser? From the CLI or in the config file?

The status of my branch is still very rough and lacking many implementations such as

• settings and overrides
• file reading and writing
• imports
• a few parameter conditions that fail

It's basically only unit tests validating that basic parsing and generation is functional.

[kyleconroy]

@jmhodges @clintberry I just merged experimental MySQL support. It's not production ready, but should work for simple queries and schema. Please try it out and report any bugs.

[jmhodges]

Wilco! Found some. Will make separate tickets (I can bring them back here and close the ones I make if you'd like)

[mightyguava]

So i was chatting with @jmhodges earlier, I'd like to recommend against vitess for a couple reasons, after talking through with systay (Andres) (maintainer of the vitess query/parsing code)

1. vitess's parser intentionally doesn't support all of mysql syntax. The parser only supports what vitess supports, intentionally failing on things that vitess does not, so the user sees an error instead of getting their statement ignored
2. if we want to add features to the parser, we would need to first add a second parsing pass that would throw on unsupported vitess features. Otherwise we would cause problems for Vitess. This is probably simple, but enumerating the features and the actual work might be tedious
3. there is an unknown number of features that the vitess parser doesn't support from the mysql syntax, and the method for discovering incompatibilities will probably be by writing test cases and parsing a ton of code examples. The burden is already being felt by @jmhodges in implementing alter support mysql alter add inside of schema file fails #251
4. while planetscale (the company that builds vitess) is in the process of expanding its mysql compatibility, extending the sql parser isn't quite on their list of priorities yet, so if we want to use their parser, the work is on us

Meanwhile, i was poking around tidb's parser, and according to this they should be fairly complete: pingcap/tidb#11486. This seems like a happier path. I'm pretty noob to compilers and AST so I could be totally wrong too.

I know @jmhodges and @jmhodges have done a ton of work around the current parser that uses Vitess, so I'm curious about your thoughts. No idea how much work would need to be redone to switch parsers. I personally am just interested in getting the best possible MySQL support so whatever gets us there is best! And I'd be happy to contribute if you think this is a good idea, I'm just a compilers noob so it might take me a while.

[cmoog]

Meanwhile, i was poking around tidb's parser, and according to this they should be fairly complete: pingcap/tidb#11486. This seems like a happier path. I'm pretty noob to compilers and AST so I could be totally wrong too.

Upon closer examination, this does look like a viable alternative to vitess. I'll take a closer look at the documentation and try to assess the work and how difficult a conversion would be.

I personally am just interested in getting the best possible MySQL support so whatever gets us there is best!

Me too! I'll definitely defer to @jmhodges on the difficulty of adding features to vitess, so I agree we should seriously consider migrating to tidbif the conversion effort justifies it.

[jmhodges]

After writing my first patch to sqlparser, I can see how we might have more work than doing a conversion to the tidb parser. I think it's someone to trying out the conversion is worth a shot.

(As a helper, do we have any contacts working on that project?)

[mightyguava]

I have contacts! Most of their company is based in China though and they currently are on the Chinese New Year holidays, till sometime next week.

Generally, I’ve found them super receptive and helpful.