[
https://issues.apache.org/jira/browse/CALCITE-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16736983#comment-16736983
]
Vladimir Sitnikov commented on CALCITE-2343:
--------------------------------------------
I've looked into the issue, and I disagree with the analysis.
Technically speaking, RexOver must not be pushed into JOIN / UNION / FILTER
since it might produce wrong result.
However, if RexOver is using just a single field, then Project(Union(x),
expr=count($0) over ()) could be transformed into Project(Union(Project(x,
$0)), expr=count($0) over ()). In other words, it could trim the set of
required columns.
However, I don't quite get the logic of PushProjector / preserveExprCondition.
[~laurentgo] would you please look into the issue one more time and update the
PR?
> PushProjector with OVER expression causing infinite loop
> --------------------------------------------------------
>
> Key: CALCITE-2343
> URL: https://issues.apache.org/jira/browse/CALCITE-2343
> Project: Calcite
> Issue Type: Bug
> Reporter: Laurent Goujon
> Assignee: Laurent Goujon
> Priority: Major
>
> When applying the {{ProjectJoinTransposeRule}} on a project with a Rex
> expression containing a RexOver call (using HepPlanner), this might cause an
> infinite loop (and ultimately a StackOverflowError exception) as
> PushProjector identify the RexOver call as to be push down under the join,
> but doesn't not rewrite correctly the top Project expression.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
