iffyio commented on code in PR #1686:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/1686#discussion_r1935083383
##########
src/dialect/mod.rs:
##########
@@ -340,12 +340,21 @@ pub trait Dialect: Debug + Any {
/// Returns true if the dialect supports lambda functions, for example:
///
/// ```sql
- /// SELECT transform(array(1, 2, 3), x -> x + 1); -- returns [2,3,4]
+ /// SELECT transform(array(1, 2, 3), (x) -> x + 1); -- returns [2,3,4]
/// ```
fn supports_lambda_functions(&self) -> bool {
false
}
+ /// Returns true if the dialect supports lambda functions without
parentheses for a single argument, for example:
+ ///
+ /// ```sql
+ /// SELECT transform(array(1, 2, 3), x -> x + 1); -- returns [2,3,4]
+ /// ```
+ fn supports_parensless_lambda_functions(&self) -> bool {
Review Comment:
hmm, given expressions `x->y` or `(x)->y`: if a dialect supports both the pg
json `->` operator and the lambda syntax then it seems to suggest an ambiguous
grammar (it doesn't seem like there's a way to tell what either expression
should be parsed into)?
My thinking was indeed to potentially turn off generic dialect and remove
`supports_parensless_lambda_functions`. Latter sounds like we'd be introducing
a behavior to the parser that is only relevant in certain cominbations, neither
covered by any of the parser's supported dialects nor a sql spec for reference
which spontaneously feels like a slippery slope.
--
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
