Adding support for IS JSON & IS NOT JSON - #2256
Conversation
55d8e29 to
3014f8c
Compare
|
Thank you for your contribution. Unfortunately, this pull request is stale because it has been open 60 days with no activity. Please remove the stale label or comment or this will be closed in 7 days. |
3014f8c to
c0e0131
Compare
6fcef30 to
411f7ba
Compare
| let cases = [ | ||
| ( | ||
| "SELECT * FROM t WHERE a IS JSON WITH FROM", | ||
| &["Expected: UNIQUE", "found: FROM"][..], |
There was a problem hiding this comment.
can we drop the exact match on the error message (they tend to change as new features are added or code is refactored) and only assert that we get a parse failure?
There was a problem hiding this comment.
I have also simplified the other analogous error matching that pre-existed and overlapped with the current edit.
| } | ||
|
|
||
| #[test] | ||
| fn parse_is_json_predicate_negative() { |
There was a problem hiding this comment.
| fn parse_is_json_predicate_negative() { | |
| fn parse_is_json_predicate_invalid() { |
| fn parse_is_json_predicate() { | ||
| use self::Expr::*; | ||
|
|
||
| let sql = "a IS JSON"; |
There was a problem hiding this comment.
can we simplify the tests a bit since the struct assertions have a lot of overlap we can have most of them only rely on the roundtrip verified_expr - I imagine it would suffice to only have one of the scenarios assert the returned struct
There was a problem hiding this comment.
Trimmed down
411f7ba to
0adc48e
Compare
0adc48e to
777cee2
Compare
iffyio
left a comment
iffyio
left a comment
There was a problem hiding this comment.
LGTM! Thanks @LucaCappelletti94!
2 participants
This PR adds support for the SQL/JSON predicate syntax
expression IS [NOT] JSON [VALUE|SCALAR|ARRAY|OBJECT] [WITH|WITHOUT UNIQUE [KEYS]], aligning with the SQL/JSON testing syntax documented by PostgreSQL (JSON Functions and Operators, Table 9.50) and Oracle (SQL/JSON Conditions IS JSON and IS NOT JSON).Implementation-wise, it introduces
Expr::IsJsonplusJsonPredicateTypeandJsonKeyUniquenessin the AST, parses the full optional modifier chain, and gates support behind a new dialect capability (supports_is_json_predicate()) enabled for Generic, ANSI, PostgreSQL, and Oracle so unsupported dialect behavior and hints remain explicit. I have included ANSI as this method in theory was introduced there in 2016.We also accept optional
KEYS(canonicalizing to include it on display) and added coverage for bothIS JSONandIS NOT JSON, malformed/junk inputs, and duplicate uniqueness clauses.