iffyio commented on code in PR #1541:
URL: 
https://github.com/apache/datafusion-sqlparser-rs/pull/1541#discussion_r1860879446


##########
src/parser/mod.rs:
##########
@@ -2935,12 +2935,23 @@ impl<'a> Parser<'a> {
             })
         } else if Token::LBracket == tok {
             if dialect_of!(self is PostgreSqlDialect | DuckDbDialect | 
GenericDialect) {
-                self.parse_subscript(expr)
+                let expr = self.parse_multi_dim_subscript(expr)?;
+                if self.dialect.support_period_map_access_key() {
+                    self.parse_map_access(expr, vec![])
+                } else {
+                    Ok(expr)
+                }

Review Comment:
   1. Not sure I fully followed what we mean by preserving syntax, do we gain 
from it from a AST-consuming pov you mean?
   2. Do you mean that those won't be possible if the representation is linear?
   
   I was primarily thinking it would be easier and more efficient to traverse 
the ast if the above variants are expressed as a chain without nesting. 
Currently, both the parser and downstream crates tend to struggle with the 
recursive nature when there's a lot of nesting going on in large/complex sql.
   
   Offhand, not sure I have a full picture of either approach though, its not 
super clear to me what the disadvantage would be with linear, or if there are 
advantages to using a nested representation
   



-- 
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: github-unsubscr...@datafusion.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org

Reply via email to