[
https://issues.apache.org/jira/browse/CALCITE-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17954901#comment-17954901
]
suibianwanwan commented on CALCITE-7045:
----------------------------------------
I didn't mark this as a bug. I believe it would work correctly if we can ensure
FieldAccess only considers the most recent Correlate with the same
correlationId as its scope. But as mentioned in the mailing list, subQuery
handling is already complex enough, so we should try to ensure CorId uniqueness
whenever possible.
One approach I can think of is to add a parameter to the RelBuilder#join method
to determine whether replaceCorrelationId is needed, while maintaining backward
compatibility with the existing code in LogicalCorrelate#create. Within
Calcite's internal rules, we should ensure that Correlate is always created
with the new correlationId.
> Generate unique correlationId for each correlate node
> -----------------------------------------------------
>
> Key: CALCITE-7045
> URL: https://issues.apache.org/jira/browse/CALCITE-7045
> Project: Calcite
> Issue Type: Improvement
> Reporter: suibianwanwan
> Priority: Major
>
> As discussed in
> [https://lists.apache.org/thread/l5ls7hxmrkp6vqqmffxs4cq4dnv95x36] :
> Currently in SubQueryRemove, new Correlates are created based on the
> CorrelationId from the original RelNode. When this subQuery requires multiple
> Correlate expansions or when multiple subQueries share the same CorrelationId
> and are expanded separately, multiple Correlates with identical CorrelationId
> may be generated.
> This can cause difficulties during Decorrelate processing and lead to errors
> in some scenarios.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
