LucaCappelletti94 commented on code in PR #2458:
URL:
https://github.com/apache/datafusion-sqlparser-rs/pull/2458#discussion_r4044429478
##########
src/dialect/mod.rs:
##########
@@ -535,10 +535,37 @@ pub trait Dialect: Debug + Any {
/// ```sql
/// SELECT transform(array(1, 2, 3), x -> x + 1); -- returns [2,3,4]
/// ```
+ ///
+ /// This enables both the `->` spelling above and the `LAMBDA` keyword
+ /// spelling gated by [`Self::supports_lambda_keyword_syntax`]. A dialect
+ /// that uses `->` as a binary operator should override only the latter.
fn supports_lambda_functions(&self) -> bool {
false
}
+ /// Returns true if the dialect supports the `LAMBDA` keyword spelling of
+ /// lambda functions, for example:
+ ///
+ /// ```sql
+ /// SELECT list_transform([1, 2, 3], lambda x : x + 1); -- returns [2, 3,
4]
+ /// ```
+ ///
+ /// This spelling does not claim the `->` token, so it can be enabled by
+ /// dialects that already give `->` a different meaning — for example JSON
+ /// member access. DuckDB uses `->` for both, resolving the ambiguity from
+ /// the function signature at bind time rather than while parsing, and
+ /// deprecated the arrow lambda form in v1.3 in favour of this one; v2.0
+ /// disables the arrow form by default.
Review Comment:
Version numbers in a doc comment go stale without anyone noticing, and the
DuckDB page you link already carries them. I think we can trim this down in
this fashion.
```suggestion
/// This spelling does not claim the `->` token, so it can be enabled by
/// dialects that already give `->` a different meaning, such as JSON
/// member access.
```
##########
tests/sqlparser_duckdb.rs:
##########
@@ -902,6 +902,24 @@ fn test_duckdb_lambda_function() {
let sql_arrow = "SELECT list_filter([1, 2, 3], x -> x > 1)";
duckdb().verified_stmt(sql_arrow);
+ // `->` is ambiguous in DuckDB: it is both the arrow lambda spelling and
+ // JSON member access, and DuckDB resolves it from the function signature
+ // at bind time. `DuckDbDialect` currently resolves it to a lambda. Both
+ // readings print identically, so round-tripping cannot tell them apart —
+ // assert the shape so any future change to that choice is visible here.
Review Comment:
The bind-time detail repeats the trait doc, I think we can deduplicate it in
this manner:
```suggestion
// Both readings of `->` print identically, so round-tripping cannot tell
// a lambda from JSON member access. Assert the shape instead.
```
--
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]
