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

Botong Huang updated CALCITE-3118:
----------------------------------
    Description: In VolcanoRuleCall.matchRecurse(), when ascending (child 
operand is matched, looking for parent operand match), we want to check that 
the matched parent indeed has the previously matched child RelNode as a child 
with the expected ordinal. However, there is a bug in this check. As a result, 
some incorrect parent is not skipped as expected and matched incorrectly. See 
unit test included in PR for a case that triggers this bug, where a second 
child RelNode get matched as first child of the parent RelNode.   (was: In 
VolcanoRuleCall.matchRecurse(), when ascending (child operand is matched, 
looking for parent operand match), we want to check that the matched parent 
indeed has the previously matched child RelNode as a child with the expected 
ordinal. However, there is a bug in this check. As a result, some incorrect 
parent is not skipped as expected and matched incorrectly. See unit test 
included in PR for a case that triggers this bug, where the same RelNode get 
matched for two operands at the same time. )

> VolcanoRuleCall match parent child ordinal not properly checked
> ---------------------------------------------------------------
>
>                 Key: CALCITE-3118
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3118
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Botong Huang
>            Priority: Major
>              Labels: pull-request-available
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> In VolcanoRuleCall.matchRecurse(), when ascending (child operand is matched, 
> looking for parent operand match), we want to check that the matched parent 
> indeed has the previously matched child RelNode as a child with the expected 
> ordinal. However, there is a bug in this check. As a result, some incorrect 
> parent is not skipped as expected and matched incorrectly. See unit test 
> included in PR for a case that triggers this bug, where a second child 
> RelNode get matched as first child of the parent RelNode. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to