yonatan-sevenai commented on code in PR #21593:
URL: https://github.com/apache/datafusion/pull/21593#discussion_r3080901606
##########
datafusion/sql/src/unparser/dialect.rs:
##########
@@ -211,6 +206,15 @@ pub trait Dialect: Send + Sync {
false
}
+ /// Unparse the unnest plan as `LATERAL FLATTEN(INPUT => expr, ...)`.
+ ///
+ /// Snowflake uses FLATTEN as a table function instead of the SQL-standard
UNNEST.
+ /// When this returns `true`, the unparser emits
+ /// `LATERAL FLATTEN(INPUT => <col>, OUTER => <bool>)` in the FROM clause.
+ fn unnest_as_lateral_flatten(&self) -> bool {
+ false
+ }
Review Comment:
Great question.
I generally followed the existing design where the dialect implementations
are policies and do not implement the changes directly. Shifting that design to
place business logic inside the dialect is possible, but I'm not sure it's
better strategy.
All in all, there are multiple touch points and multiple areas to go from
Datafusion UNNEST forms into Snowflake's lateral movements.
Specifically in the test cases I've added I've built unnest from the result
of a UDF (consider `select UNNEST(ExtractArrayFromCol(col)) from table` and
other cases where the DF optimizer is putting Limit, Sort, multiple layers of
SubqueryAlias and other nodes inside the DF logical plan. Handing all of these
felt like something to big and invasive to add to the dialect traints.
But as I said, the real motivation was to keep the dialect as slim as
possible (like today), and not introduce very partial overridable behaviors
into the various Unparser as dialect hooks to structurally alter the Unparsed
output.
WDYT @goldmedal ?
--
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]
