apache / apache/datafusion-sqlparser-rs
Postgres does not limit which operators can be used with `ANY` and `ALL`
- 主要言語
- Rust
- スター
- 3.5k
- フォーク
- 772
- 平均マージ
- 4日 9時間
- マージ済み PR(30日)
- 17
説明
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.
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
ANY/ALL の演算子 allowlist が適用されている src/parser/mod.rs:2893-2908 から始め、そこで Postgres 方言がどのように表現されているかを確認してください。例における Postgres の動作を、既存の非 Postgres 制限と比較してください。Postgres がこれらの式に対して任意の二項演算子を受け入れ、他の方言では現在の allowlist が維持されれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- postgresql, rust
- 領域
- databases
- issue の種類
- バグ
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 活発さ
- 停滞
- 明瞭さ
- 明確に書かれている
- 初心者へのやさしさ
- 35/100