Skip to content

Inconsistent handling of Postgres infix operators #816

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
joocer opened this issue Feb 25, 2023 · 3 comments
Closed

Inconsistent handling of Postgres infix operators #816

joocer opened this issue Feb 25, 2023 · 3 comments

Comments

@joocer
Copy link
Contributor

joocer commented Feb 25, 2023

There appear to be some Postgres operators which are supported in the base dialect and some that are only supported in the Postgres dialect, but I'm not able to work out why from looking at the code. See below, it looks like >> is in Postgres and Generic, but ~ is everywhere.

            Token::ShiftRight if dialect_of!(self is PostgreSqlDialect | GenericDialect) => {
                Some(BinaryOperator::PGBitwiseShiftRight)
            }
            Token::Sharp if dialect_of!(self is PostgreSqlDialect) => {
                Some(BinaryOperator::PGBitwiseXor)
            }
            Token::Tilde => Some(BinaryOperator::PGRegexMatch),
            Token::TildeAsterisk => Some(BinaryOperator::PGRegexIMatch),

Is this a bug in the implementation (should tilde be only applicable to Postgres / ShiftRight be available to all) or is there a missing comment as to why this distinction exists?

@AugustoFKL
Copy link
Contributor

@joocer, the operator handling is quite faulty right now for two reasons:

  • The operators vary from dialect;
  • (more critical) Their precedence varies between dialects.

The fact that we try to do all parsing together makes it hard to handle specific logic properly. As I commented on #814, I would love to review a new implementation, but I can work directly on that. It is too much, and for now, I only plan on working on the following:

  • Review PRs
  • Review issues
  • Solve small generic PRs (e.g., add a keyword for a statement here, a data type there, etc.)
  • MySQL and PostgreSQL specific syntax

Besides that, I can't guarantee anything for the next month, at least considering the pacing I'm taking. Sorry about that.

@joocer
Copy link
Contributor Author

joocer commented Feb 25, 2023

Thanks @AugustoFKL, rather than two issues that touch on each other, I suggest this one be closed off, it looks like michael-2956 is probably in a better position to progress as I'm not much of a rust developer (I'm using this library in Python via SqlOxide).

@joocer joocer closed this as not planned Won't fix, can't repro, duplicate, stale Feb 25, 2023
@AugustoFKL
Copy link
Contributor

@joocer lovely to know! Thanks for the information; it makes me wanna work even more here to support everyone using this!!

Promise you that the precedence will be fixed within the next month, even if @michael-2956 doesn't work on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants