goldmedal commented on code in PR #13660:
URL: https://github.com/apache/datafusion/pull/13660#discussion_r1878058721
##########
datafusion/sql/src/unparser/dialect.rs:
##########
@@ -157,6 +157,15 @@ pub trait Dialect: Send + Sync {
fn full_qualified_col(&self) -> bool {
false
}
+
+ /// Allow to unparse the unnest plan as [ast::TableFactor::UNNEST].
+ ///
+ /// Some dialects like BigQuery require UNNEST to be used in the FROM
clause but
+ /// the LogicalPlan planner always put UNNEST in the SELECT clause. This
flag allows
Review Comment:
> well, UNNEST is a lateral relational operator. It doesn't belong to the
select clause. It's probably yet another witness of the problem that the LP is
half way between AST and a good IR (which we don't have yet)
>
Interesting.
The logical planner plans `FROM unnest([1,2,3])` to
```
Projection:
unnest_placeholder(make_array(Int64(1),Int64(2),Int64(3)),depth=1) AS
UNNEST(make_array(Int64(1),Int64(2),Int64(3)))
Unnest:
lists[unnest_placeholder(make_array(Int64(1),Int64(2),Int64(3)))|depth=1]
structs[]
Projection: make_array(Int64(1), Int64(2), Int64(3)) AS
unnest_placeholder(make_array(Int64(1),Int64(2),Int64(3)))
EmptyRelation
```
Do you think it's a good plan? What would a good IR look like? 🤔
--
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]
