Skip to content

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

Open
@andygrove

Description

@andygrove
No description provided.

Activity

added this to the Milestone 1 milestone on Oct 6, 2018
added a commit that references this issue on Aug 26, 2019

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

c17eb41
alex-dukhno

alex-dukhno commented on Jul 8, 2020

@alex-dukhno
Contributor

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

bigkraig commented on Jul 14, 2020

@bigkraig

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

nickolay

nickolay commented on Jul 17, 2020

@nickolay
Contributor

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.

added a commit that references this issue on Feb 18, 2022
eca5b86
added a commit that references this issue on Nov 1, 2023
added a commit that references this issue on Mar 15, 2024

1 remaining item

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nickolay@bigkraig@andygrove@alex-dukhno

        Issue actions

          Produce design for writing custom SQL parsers by extending this library · Issue #7 · apache/datafusion-sqlparser-rs