[
https://issues.apache.org/jira/browse/CALCITE-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-2865:
-----------------------------------------
Summary: FilterProjectTransposeRule generates wrong traitSet when
copyFilter/Project is true (was: FilterProjectTransposeRule generates
different traitSet depending on copyFilter / copyProject flags)
> FilterProjectTransposeRule generates wrong traitSet when copyFilter/Project
> is true
> -----------------------------------------------------------------------------------
>
> Key: CALCITE-2865
> URL: https://issues.apache.org/jira/browse/CALCITE-2865
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.18.0
> Reporter: Ruben Quesada Lopez
> Priority: Major
>
> Problem can be reproduced with the following test:
> {code}
> @Test public void testFilterProjectTransposeRule() {
> CalciteAssert.that()
> .withSchema("s", new ReflectiveSchema(new JdbcTest.HrSchema()))
> .query("?")
> .withRel(b -> b
> .scan("s", "emps")
> .filter(b.equals(b.field(1), b.literal(10))) // deptno = 10
> .sort(-4) // salary desc
> .project(b.field(3)) // salary (**)
> .filter(b.equals(b.field(0), b.literal(11500))) // salary =
> 11500 (**)
> .build())
> .returnsOrdered("salary=11500.0");
> }
> {code}
> If we run the test with a break point at the end of
> {{FilterProjectTransposeRule#onMatch}} method, we can see that, when the
> project and filter tagged with (**) are transposed, the generated output
> (newFilterRel) is different in terms of traitSet, depending if the copyFilter
> / copyProject flags are used or not:
> - copyFilter and copyProject TRUE (default)
> {code}
> LogicalProject.NONE.[0 DESC]
> LogicalFilter.NONE.[0 DESC] // !!!
> LogicalSort.NONE.[1 DESC]
> {code}
> - copyFilter and copyProject FALSE
> {code}
> LogicalProject.NONE.[0 DESC]
> LogicalFilter.NONE.[1 DESC] // !!!
> LogicalSort.NONE.[1 DESC]
> {code}
> As I see it, the default behavior seems wrong in terms of new filter's
> traitSet, although the test run successfully (maybe because other rules
> intervene to build the final plan?).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
