[jira] [Updated] (CALCITE-988) FilterToProjectUnifyRule.invert(MutableRel, MutableRel, MutableProject) works incorrectly

["Maryann Xue (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maryann Xue updated CALCITE-988:
--------------------------------
    Attachment: CALCITE-988.patch

[~julianhyde] Would you mind reviewing this patch?

> 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)