Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
added parsing for PostgreSQL operations #267
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
added parsing for PostgreSQL operations #267
Changes from 2 commits
c1dd27d
0df8011
1f2b8d3
045dbf5
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably not right, as this parses
WHERE ||/27 = 3
as||/ ( 27=3 )
, which is not a valid expression. I don't see precedence mentioned in the documentation you linked to, and I think a better guess would be to default all the unary operators to thePLUS_MINUS_PREC
(moving the new ops to thetok @
case below).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we'd consider how postfix factorial interacted with other operators (the postfix
::type
, another factorial, and prefix operators), but I don't think this has to block merging this PR.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nickolay, am I right that this is not going to work with custom dialect as you suggest here #243 (comment)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry, but I don't follow. In the comment you mention I said I didn't think that simply allowing
$
to start an identifier matched what the PosgreSQL documentation said about this.In this PR you make
|/
conditionally parse asSquareRoot
, which makes sense to me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have custom
Dialect
https://github.com/alex-dukhno/database/blob/master/src/parser/src/lib.rs#L221-L231, is it true that it wouldn't parse|/
intoSquareRoot
because ofif dialect_of!(self is PostgreSqlDialect)
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see now. Yes, I assumed
|/
is something very Postgres-specific, so limiting it to PostgreSqlDialect (and GenericDialect, which I didn't mention explicitly) seemed to make sense.In the older comment you're referring to I described a stop-gap measure that would be used until someone figured out the proper way to deal with
$...
in the parser.We could make the new operators parse unconditionally for now if that makes your life easier, but without a clear use-case (and accompanying testcase) this will likely break in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to have
dialect_of
checks and have a solution for dealing with$...
. Having my knowledge of crate I'd suggest to addVariable(Ident)
or something similar toast::Expr
enum. It has to be done in a separate PR of course. WDYT?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have @-mentioned you in #265, where this discussion can continue.
The hard part is describing what specifically we're trying to implement and why. Your suggestion, for example, solves the problem of representing
$
(but not another leader) followed by an identifier (quoted or not; consisting of characters from an unspecified set) anywhere an arbitrary expression is allowed (but not in more restricted contexts, likeOFFSET __ ROWS
). I'm not sure if this matches Postgres or the "common denominator" of the usual dialects; answering that requires some research. From the examples I've seen so far, a newValue
variant with{leader, ident}
fields might be more appropriate.