goldmedal commented on issue #15128: URL: https://github.com/apache/datafusion/issues/15128#issuecomment-2714188905
> The easiest fix I can think of is to add info about the location of the unnest in the `__unnest_placeholder`, similarly to how we currently add `depth`. With that, we'll try to put it into relation _only_ if it was originally in the relation. I'm not sure about that. The problem is here: https://github.com/apache/datafusion/blob/304488d348ad2c952ce24f93064a81046155da79/datafusion/sql/src/unparser/plan.rs#L874 If `with_unnest_as_table_factor` is enabled, we will try to keep `unnest` in the from clause, but I never consider the case you propose 🤔. It seems to be another pattern we should handle in the unparser. If we disable `with_unnest_as_table_factor`, it works well: ```sql SELECT UNNEST([1, 2, 3, 4]) AS "UNNEST(make_array(Int64(1),Int64(2),Int64(3),Int64(4)))" FROM (SELECT UNNEST([1, 2, 3]) AS "UNNEST(make_array(Int64(1),Int64(2),Int64(3)))") ``` So, another option, `with_unnest_as_table_factor` is designed (https://github.com/apache/datafusion/issues/13601) for dialects that only allow the use of `unnest` as a table factor (e.g., BigQuery). Perhaps we can simply throw an error when encountering this type of case if `with_unnest_as_table_factor` is enabled? -- 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]
