[
https://issues.apache.org/jira/browse/CALCITE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190354#comment-17190354
]
Julian Hyde commented on CALCITE-4225:
--------------------------------------
Let's be careful here. It may be to your organization's benefit that
{{RelDecorrelator} is pluggable, but it may not be to Calcite's benefit. For
instance, this might make it easier to fork the decorrelator, and now we have
different sub-communities operating on different assumptions.
Can we add configuration parameters to {{RelDecorrelator}}? (And add tests each
time we add a new parameter.)
Can we make use of planner rules (such as
{{RemoveCorrelationForScalarProjectRule}}), and have planner rules be the
'pluggability' mechanism?
> Make RelDecorrelator pluggable
> ------------------------------
>
> Key: CALCITE-4225
> URL: https://issues.apache.org/jira/browse/CALCITE-4225
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.25.0
> Reporter: Danny Chen
> Assignee: Danny Chen
> Priority: Major
> Fix For: 1.26.0
>
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But
> actually, the pattern it can decorrelate successfully is very limited. And it
> often causes bug because it decorrelates into a wrong plan (with non-correct
> sementics).
> When there are bugs there, the downstream project can only wait for the
> version upgrade (if it is fixed in Calcite master), or they copy the whole
> Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we
> can control how a RelNode was decorrelated(not a coarse-grained flag to
> turn-on/off the decorrelation).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
