LucaCappelletti94 commented on code in PR #2344:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2344#discussion_r3280020623
##########
src/parser/mod.rs:
##########
@@ -2050,14 +2052,9 @@ impl<'a> Parser<'a> {
})?;
match expr {
- // If we get back a compound field access or
identifier,
- // we flatten the nested expression.
- // For example if the current root is `foo`
- // and we get back a compound identifier
expression `bar.baz`
- // The full expression should be `foo.bar.baz`
(i.e.
- // a root with an access chain with 2 entries) and
not
- // `foo.(bar.baz)` (i.e. a root with an access
chain with
- // 1 entry`).
+ // `parse_prefix` does not itself follow compound
chains, but a
+ // dialect override could still return a compound
expression, so
+ // keep the flatten arms for safety.
Review Comment:
Restored in 43152a24 (well, in e1910856). You're right, the old comment
still applies to the flatten arms unchanged.
##########
tests/sqlparser_postgres.rs:
##########
@@ -9243,3 +9243,27 @@ fn parse_lock_table() {
}
}
}
+
+/// `parse_compound_expr` used to do 2^N work on `IF a.b.c...x.#` because every
+/// `.` re-entered `parse_subexpr` over the rest of the chain.
+#[test]
+fn parse_compound_chain_no_exponential_blowup() {
Review Comment:
Moved to sqlparser_bench in 43152a24 as parse_compound_chain (using
GenericDialect, since the fix is in shared parser code). Bench parses chains of
length 10/20/30 ending in an invalid suffix, currently ~10us / 26us / 49us.
Pre-fix it was 2^N.
--
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]
