Produce design for writing custom SQL parsers by extending this library #7

Activity

1. andygrove

   added this to the Milestone 1 milestone on Oct 6, 2018
2. benesch

   added a commit that references this issue on Aug 26, 2019

   Merge pull request #7 from MaterializeInc/ast-literal-docs

   ...

   c17eb41
3. alex-dukhno commented on Jul 8, 2020

   

   alex-dukhno

   on Jul 8, 2020

   Contributor

   More actions

   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.

   👍React with 👍3Reacted by Bulat Fattakhov, Kraig Amador and eyalleshem
4. bigkraig commented on Jul 14, 2020

   

   bigkraig

   on Jul 14, 2020

   More actions

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

   👍React with 👍1Reacted by Alexander Dukhno
5. nickolay commented on Jul 17, 2020

   

   nickolay

   on Jul 17, 2020

   Contributor

   More actions

   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.
6. flaneur2020

   added a commit that references this issue on Feb 18, 2022

   Merge pull request apache#7 from zhyass/main

   ...

   eca5b86
7. Taylor-lagrange

   added a commit that references this issue on Nov 1, 2023

   feat: support range expr parse (apache#7)

   ...

   602d787
8. serprex

   added a commit that references this issue on Nov 6, 2023

   Visitor for function arguments expressions (apache#7)

   a879adf
9. jmhain

   added a commit that references this issue on Mar 15, 2024

   merge Sigma changes into main branch (apache#9)

   ...

   8dcc913
10. LucaCappelletti94 commented on Sep 23, 2026

    

    LucaCappelletti94

    on Sep 23, 2026

    Contributor

    More actions

    Completed on current main, custom dialects extend the parser through the Dialect trait hooks.
11. LucaCappelletti94

    closed this as completedon Sep 23, 2026