[
https://issues.apache.org/jira/browse/CALCITE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue resolved CALCITE-988.
---------------------------------
Resolution: Fixed
> FilterToProjectUnifyRule.invert(MutableRel, MutableRel, MutableProject) works
> incorrectly
> -----------------------------------------------------------------------------------------
>
> Key: CALCITE-988
> URL: https://issues.apache.org/jira/browse/CALCITE-988
> Project: Calcite
> Issue Type: Bug
> Reporter: Maryann Xue
> Assignee: Maryann Xue
> Priority: Minor
> Fix For: 1.6.0
>
> Attachments: CALCITE-988.patch
>
>
> The below code does not "invert" but only projects what's been projected. A
> type mismatch exception would be thrown when creating the new MutableProject.
> {code}
> for (Ord<RexNode> expr : Ord.zip(project.getProjects())) {
> if (expr.e instanceof RexInputRef) {
> final int target = ((RexInputRef) expr.e).getIndex();
> exprList.set(expr.i,
> rexBuilder.ensureType(expr.e.getType(),
> RexInputRef.of(target, input.rowType),
> false));
> } else {
> throw MatchFailed.INSTANCE;
> }
> }
> {code}
> However, the exposure of this bug is quite low. Actually I couldn't find a
> query that would go through this code path, coz looks like any query that has
> a Filter will have a Project on top of that, which makes it go the other
> branch and use the other invert() method. A filtered view will produce a
> Filter on top of another Filter thus can reproduce this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
