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