You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
wait until the issue will be solved by someone else,
fork the crate and work on only PostgreSQL dialect,
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.
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.
Activity
Merge pull request #7 from MaterializeInc/ast-literal-docs
alex-dukhno commentedon Jul 8, 2020
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:
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 commentedon Jul 14, 2020
Same boat as @alex-dukhno, except that I want to extend this to support SqlAnywhere
nickolay commentedon Jul 17, 2020
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.
Merge pull request apache#7 from zhyass/main
feat: support range expr parse (apache#7)
Visitor for function arguments expressions (apache#7)
merge Sigma changes into main branch (apache#9)
1 remaining item