LucaCappelletti94 commented on code in PR #2899:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2899#discussion_r4564305320
##########
src/parser/mod.rs:
##########
@@ -1927,11 +1942,27 @@ impl<'a> Parser<'a> {
format: None,
})
}
- data_type => Ok(Expr::TypedString(TypedString {
- data_type,
- value: parser.parse_value()?,
- uses_odbc_syntax: false,
- })),
+ data_type => {
+ if parser.in_subscript_bound
Review Comment:
Would it be better to drop `in_subscript_bound` and reject a typed string
whose innermost square-bracket element type is `DataType::Custom`, next to the
existing `DataType::Custom(..) => parser_err!("dummy", loc)` arm?
`bounds[1]` gets past that arm only because it parses as an array of a
custom type. With that check on `main` and none of the flag or cache-key
changes, every new test passes except
`parse_array_slice_failure_does_not_poison_array_expression`, which only guards
the cache keys. PostgreSQL 18 rejects every array type in the `type 'string'`
form, `SELECT int[2] '{1,2}'` included, so no valid PostgreSQL input is lost.
##########
src/parser/mod.rs:
##########
Review Comment:
Would the check on the typed-string arm also avoid this leak?
`parse_subexpr` keeps `in_subscript_bound` set inside `POSITION(...)`, so
`tags[POSITION(INT[2] :items IN 'x'):3]` fails in PostgreSQL with `Expected: (,
found: 'x'` and loses its typed string in Generic and DuckDB, where `main`
parses it.
##########
src/parser/mod.rs:
##########
Review Comment:
Would the check on the typed-string arm also avoid this leak? The map key
inherits `in_subscript_bound`, so `tags[MAP {INT[2] :a: 1}:4]` is rejected in
Generic and DuckDB, where `main` parses it.
--
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]
