[jira] [Commented] (CALCITE-3922) ProjectRemoveRule drops aliases when used with HepPlanner

["Julian Hyde (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-3922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17083497#comment-17083497 ] 

Julian Hyde commented on CALCITE-3922:
--------------------------------------

I'm not very surprised by this. Rules don't commit to preserving column aliases (although they try their best). {{ProjectRemoveRule}}'s job is to remove identity projects (which were likely added for renaming purposes anyway) and it is not part of its remit to re-shape the input, so I don't see that it can achieve the goal of retaining aliases.

Note that {{ProjectRemoveRule}} only has one argument, therefore it is not able to see its unwrapped input.

{{ProjectMergeRule}} might be a better candidate for what you want. If it merges two projects it is much more likely to retain the upper project's alias. Even if the upper project is an identity or a permutation.

If the goal is to generate SQL with particular column names, sometimes the column names in the {{RelNode}} just don't match up. IIRC {{RelToSqlConverter}} has a data structure that contains the desired column aliases, and they take precedence over the {{RelNode}} field names.

> 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
>            Priority: Major
>
> 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)