Produce design for writing custom SQL parsers by extending this library

[andygrove]

No description provided.

[alex-dukhno]

Hi guys, I am building a PostgreSQL compatible NewSQL database and using sqlparse-rs. I haven't encountered problems with supporting different dialects until I started working on mathematical operations that PostgreSQL supports.
I don't know how big problem to add ! factorial, !! prefix factorial, |/ square root and ||/ cube root to the parser, however, it is a problem for bitwise xor which is ^ in SQL standard and # in PostgreSQL (^ is an exponent in PostgreSQL). So I think this issue becomes somewhat critical for my project.
Currently, I see 3 possible ways for me:

1. wait until the issue will be solved by someone else,
2. fork the crate and work on only PostgreSQL dialect,
3. contribute back to sqlparse-rs crate.

I am leaning to 3) option because 1) I assume will take a long time, 2) it will be a big burden for me in testing and backporting useful feature from sqlparse-rs.

The biggest obstacle for me to start contributing on the topic of the issue is that I haven't seen the "roadmap" or "design discussion" on how to make sqlparse-rs customisable for dialects. So I'd like to see if maintainers, contributors, and community have ideas or something that we could try out and start moving on the issue.

[bigkraig]

Same boat as @alex-dukhno, except that I want to extend this to support SqlAnywhere

[nickolay]

We currently accept dialect-specific extensions in the mainline parser, trying to document the differences between the dialects as we add support for more syntax.

We don't have many examples where we weren't able to do so (#223 comes to mind, but that dialect's grammar is undocumented). I do expect that we'll have to add dialect-specific parsing at some point, probably using the approaches I wrote about in #207. Not sure if adding the operators you mention is blocked by that, probably not?

I also believe that a strictly typed Syntax tree, which we currently have, is the main limiting factor to exploring various designs to better support dialects. That's why I opened #189 in order to unblock others who may be willing to help with that.