freshtonic opened a new issue, #1841:
URL: https://github.com/apache/datafusion-sqlparser-rs/issues/1841
In PR #963 a check was introduced which limits which operators can be used
with `ANY` and `ALL` expressions.
Postgres can parse more (possibly _all_ binary operators, investigation
pending) in this location. Postgres only seems to care that the operator yields
a boolean - which is a semantic error, not a syntax (parse) error.
Example (semantic error, not a parse error):
```
select 123 % ANY(array[246]);
ERROR: op ANY/ALL (array) requires operator to yield boolean
LINE 1: select 123 % ANY(array[246]);
^
```
The following code in `src/parser/mod.rs:2893-2908` is where the allowlist
of operators is enforced:
```rust
if !matches!(
op,
BinaryOperator::Gt
| BinaryOperator::Lt
| BinaryOperator::GtEq
| BinaryOperator::LtEq
| BinaryOperator::Eq
| BinaryOperator::NotEq
) {
return parser_err!(
format!(
"Expected one of [=, >, <, =>, =<, !=] as comparison operator,
found: {op}"
),
tok.span.start
);
};
```
I propose that instead of hard-coding the allowed operators we instead check
if the dialect is Postgres, and if so allow arbitrary `BinaryOperator`s to be
used. Existing behaviour will be preserved for all other dialects.
This is a blocker for a new customer at my day job - I will do the work
myself - so really I'm looking for feedback on the suggested approach.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
