Are you looking at the RelRoot's field names or the field names of the RelNodes in the plan? The names of the fields in RelNodes are semantically meaningless in Calcite's eyes (rule semantics are based on ordinal position, not field name). The validated row type (and correct field names) may only exist in the RelRoot.validatedRowType. Sometimes the RelNode of the output of the plan matches this RowType but often it does not.
On Tue, Nov 23, 2021 at 10:47 PM Yanjing Wang <[email protected]> wrote: > Hi, team > I'm using ProjectRemoveRule to simplify my logical plan, But the plan > sometimes miss its project alias, I find the rule hasn't checked the alias > for project row type identity equation, so I think it may be a bug, I have > tried to reproduce the problem, but I failed to build two projects. > > I have tried the following but the plan always ignores the alias: > > final Function<RelBuilder, RelNode> relFn = b -> { > RelNode plan = b.scan("EMP") > .project( > b.field("DEPTNO"), > b.field("ENAME") > ) > .project( > b.alias(b.field(0), "DEPTNO_ALIAS"), > b.alias(b.field(1), "ENAME_ALIAS") > ) > .build(); > return plan; > }; > > relFn(relFn) > .withRule( > CoreRules.PROJECT_REMOVE) > .withRelBuilderConfig(b -> b.withBloat(-1)) > .check(); > > > So I resort to modifying existing test case to reproduce, I change > the testUnionMergeRule test case in RelOptRulesTest.java. I change its > final projection *** to *name as ename, deptno as edeptno*, > and the plan miss the alias again. I think the hep rules shouldn't remove > the alias which are output column label. >
