[
https://issues.apache.org/jira/browse/CALCITE-7608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18103555#comment-18103555
]
Mihai Budiu commented on CALCITE-7608:
--------------------------------------
I have revised the title and scope of this issue. Initially it comprised three
different sub-tasks, the first two of which have already been merged. The first
two subtasks could be considered bug-fixes or improvements in the semantics of
Unnest, which didn't fully support its original intended use cases.
This issue has been shrunk to cover only the third task. It proposes extending
the semantics of Unnest in a simple, backwards-compatible way. I will amend the
original PR, which did all 3 tasks, hopefully it will become much smaller and
easier to review, and hopefully to accept as well. [~zwh] I believe that the
final implementation will cover all the use cases you have highlighted in your
analysis above. (The LEFT JOIN semantics is already covered at this point).
> Enhance Uncollect to support pass-through fields
> ------------------------------------------------
>
> Key: CALCITE-7608
> URL: https://issues.apache.org/jira/browse/CALCITE-7608
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.42.0
> Reporter: Mihai Budiu
> Assignee: Mihai Budiu
> Priority: Minor
> Labels: pull-request-available
>
> Today SQL UNNEST is implemented using the Uncollect operator. We propose
> adding an additional capability to Uncollect, which generalize its current
> behavior:
> * support for carrying over non-collection input fields to the output
> unchanged
> This would strictly increase the expressive power of Uncollect, allowing it
> to not only Unnest collections, but also copy some input fields unchanged for
> every element of an unnested collection.
> This would enable us to represent plans using SQL UNNEST without using
> Correlate nodes. A sub-plan containing Project + Correlate + Uncollect +
> Values would become a single Uncollect node. Neither the old nor the new
> decorrelator can actually eliminate Correlate + Uncollect (there is no other
> representation to express the same behavior). Using the new representation we
> can decorrelate many more plans (perhaps all plans).
> A temporary configuration flag would be introduced to control whether
> SqlToRelConverter uses the new form of the operator, or just the old form.
> Hopefully programs that only use the old form would remain unchanged. This
> will give Calcite users time to upgrade to the new representation at their
> own pace.
> This builds on top of the changes made to Uncollect in CALCITE-7670
> CALCITE-7669 , but is an independent feature of these two changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
