Planner rules do their best to keep field names the same, but they don’t guarantee it. If they did, they’d miss a lot of good opportunities to optimize.
By the way, the same goes for RelBuilder. Julian > On Jan 18, 2018, at 3:50 PM, Shuyi Chen <suez1...@gmail.com> wrote: > > Hi, > > I have a question regarding the ProjectRemoveRule. In Calcite 1980, a test > case was introduced below: > > /** Test case for > * <a href="https://issues.apache.org/jira/browse/CALCITE-1980";>[CALCITE-1980] > * RelBuilder gives NPE if groupKey contains alias</a>. > * > * <p>Now, the alias does not cause a new expression to be added to the input, > * but causes the referenced fields to be renamed. */ > @Test public void testAggregateProjectWithAliases() { > final RelBuilder builder = RelBuilder.create(config().build()); > RelNode root = > builder.scan("EMP") > .project(builder.field("DEPTNO")) > .aggregate( > builder.groupKey( > builder.alias(builder.field("DEPTNO"), "departmentNo"))) > .build(); > final String expected = "" > + "LogicalAggregate(group=[{0}])\n" > + " LogicalProject(departmentNo=[$0])\n" > + " LogicalProject(DEPTNO=[$7])\n" > + " LogicalTableScan(table=[[scott, EMP]])\n"; > assertThat(str(root), is(expected)); > } > > So according the ProjectRemoveRule, which will remove the top project, the > above REL will be optimized as the following: > > LogicalAggregate(group=[{0}]) > LogicalProject(DEPTNO=[$7]) > LogicalTableScan(table=[[scott, EMP]]) > > But this will lose rename information "departmentNo". Is this expected, and > is it a problem that should get fixed? Please correct me if I am wrong. > Thanks a lot. > > Shuyi > -- > "So you have to trust that the dots will somehow connect in your future."
