Skip to content

Parser: fix IS [NOT] DISTINCT FROM right-operand precedence - #2443

Closed
MohamedAbdeen-rs wants to merge 1 commit into
apache:mainfrom
readysettech:is-distinct-from-precedence-upstream
Closed

Parser: fix IS [NOT] DISTINCT FROM right-operand precedence#2443
MohamedAbdeen-rs wants to merge 1 commit into
apache:mainfrom
readysettech:is-distinct-from-precedence-upstream

Conversation

@MohamedAbdeen-rs

Copy link
Copy Markdown

IS DISTINCT FROM and IS NOT DISTINCT FROM parsed their right operand with parse_expr, which starts at the lowest precedence and therefore absorbed every operator that followed, including AND and OR. So a IS DISTINCT FROM b AND c parsed as a IS DISTINCT FROM (b AND c) instead of (a IS DISTINCT FROM b) AND c.

PostgreSQL places IS below the comparison operators and above NOT, AND and OR. Precedence::Is already encodes exactly that.

`IS DISTINCT FROM` and `IS NOT DISTINCT FROM` parsed their right operand
with parse_expr, which starts at the lowest precedence and therefore
absorbed every operator that followed, including AND and OR. So
`a IS DISTINCT FROM b AND c` parsed as `a IS DISTINCT FROM (b AND c)`
instead of `(a IS DISTINCT FROM b) AND c`, accepting a boolean operand
where PostgreSQL takes the comparison as complete.

PostgreSQL places IS below the comparison operators and above NOT, AND
and OR. `Precedence::Is` already encodes exactly that, and the operator
is dispatched with it; only the right operand ignored it. Every other
infix operator in parse_infix parses its right operand with
parse_subexpr(precedence), so do the same for these two.

Operators binding tighter than IS still join the right operand, so
`a IS DISTINCT FROM b + c` and `a IS DISTINCT FROM b = c` are unchanged,
and a parenthesized conjunction still reaches it. Adds precedence tests
for both spellings against AND, OR, NOT, `+`, `=`, parentheses, and a
WHERE clause conjoining two of these comparisons.
@LucaCappelletti94

Copy link
Copy Markdown
Contributor

Seems like a duplicate of #2436, could you please check and determine whether this PR should be closed in favour of the pre-existing one?

@adriangb

Copy link
Copy Markdown

Seems like a duplicate of #2436, could you please check and determine whether this PR should be closed in favour of the pre-existing one?

I looked at both and I think #2436 is more complete. I suggest we close this PR. Thanks for your contribution @MohamedAbdeen-rs

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

Successfully merging this pull request may close these issues.

3 participants