3 ms·
I have unrelated request since you are planning to add sql parser to your project. Would it be possible to have sql parser as seperate library? I am in need of
by newusertoday 5y ago
I have unrelated request since you are planning to add sql parser to your project. Would it be possible to have sql parser as seperate library? I am in need of sql parser and so far i have only been able to get parsers for specific dialects like pingcap parser for mysql. I think sql parser that can support multiple different sql dialects would be a great addition to golang ecosystem.
- rotemtam 5y agohey, Yes, indeed that's part of our plan! If you want to chat about it, join us on our discord server? https://discord.com/invite/QhsmBAWzrC https://discord.com/invite/QhsmBAWzrC
- a8m 5y agoI agree with that as well. The idea is to create an infrastructure for SQL parsers. Base parser will hold all standard structure and dialects can register custom clauses/statements. At the moment, I generate PEG files for each dialect, but this creates too much duplicate code, and does not allow sharing same types/objects between different dialects. I thought about keeping it on the same GitHub repository (https://github.com/ariga/atlas https://github.com/ariga/atlas), but as a separate Go module? WDYT?
- newusertoday 5y ago+1, separate go module looks good to me.
- tpetry 5y agoThat would be really usefull! And when the parser does not understand a language construct (e.g. a new swl fwature) let it fall back to some dumb parsing for that part. If it does not under „LIMIT 5 WITH TIES“ let it parse „LIMIT 5“ in it‘s usefull abstraction and just provide two suffix keywords „WITH“ and „TIES“.