Steven Talbot created CALCITE-3922: -------------------------------------- Summary: ProjectRemoveRule drops aliases when used with HepPlanner Key: CALCITE-3922 URL: https://issues.apache.org/jira/browse/CALCITE-3922 Project: Calcite Issue Type: Bug Reporter: Steven Talbot
The line at [https://github.com/apache/calcite/blob/15fa9bc67a8ed12ec6b8e0d1dbced8760ae307ab/core/src/main/java/org/apache/calcite/rel/rules/ProjectRemoveRule.java#L67] checks for the input being an instanceof Project, but in the HepPlanner every input is always a HepRelVertex. I struggled writing a test for this, but I finally got one (in HepPlannerTest). The thing the test does is similar to how I hit this: you tend to only have trivial projects on top of other trivial projects if a rule moved them around. RelBuilder and SqlToRelConverter will just pre-squash them for you. {code:java} @Test public void testProjectRemoveRuleWithAliases() { HepProgram prog = HepProgram.builder() .addRuleInstance(FilterProjectTransposeRule.INSTANCE) .addRuleInstance(ProjectRemoveRule.INSTANCE) .build(); HepPlanner planner = new HepPlanner(prog); RelBuilder relBuilder = RelBuilder.create(Frameworks.newConfigBuilder().build()); String[] fieldNames = {"name", "other"}; relBuilder.values(fieldNames, "something", "something else"); relBuilder.project(relBuilder.field("name")); // add a filter so the projects won't squash together: it will be moved below by the transpose rule relBuilder.filter(relBuilder.call(SqlStdOperatorTable.LIKE, relBuilder.field("name"), relBuilder.literal("something"))); relBuilder.rename(ImmutableList.of("name1")); planner.setRoot(relBuilder.build()); RelNode opt = planner.findBestExp(); assertEquals(LogicalValues.class, opt.getInput(0).getInput(0).getClass(), "should have removed the project"); assertEquals("name1", opt.getRowType().getFieldNames().get(0), "should have kept the rename"); } {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)