Assertions failing in VolcanoPlanner from logical optimization / CalcRemoveRule

[Kenneth Knowles <ke...@apache.org>]

Hi all,

I have been working on converting Beam SQL from have its own Project/Filter
implementations to just using Calc. (PR at
https://github.com/apache/beam/pull/5544)

Basically, this diff to the rule set:

    +          // Rules so we only have to implement Calc
    +          FilterCalcMergeRule.INSTANCE,
    +          ProjectCalcMergeRule.INSTANCE,
    +          FilterToCalcRule.INSTANCE,
    +          ProjectToCalcRule.INSTANCE,
    +          CalcRemoveRule.INSTANCE,
    +          CalcMergeRule.INSTANCE,

I always hit assertion errors in the VolcanoPlanner when CalcRemoveRule is
invoked, because:

 - LogicalCalc.create always results in a composite collation trait
 - VolcanoPlanner asserts that there are no composite traits
 - There's no simplify() in between the two (I'm not sure there can be)

The stack trace (Calcite 1.16.0) is this:

java.lang.AssertionError
at
org.apache.calcite.plan.volcano.VolcanoPlanner.changeTraits(VolcanoPlanner.java:546)
at org.apache.calcite.plan.RelOptRule.convert(RelOptRule.java:540)
at
org.apache.calcite.rel.rules.CalcRemoveRule.onMatch(CalcRemoveRule.java:65)
at
org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
at
org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
at org.apache.calcite.tools.Programs$RuleSetProgram.run(Programs.java:368)
at org.apache.calcite.prepare.PlannerImpl.transform(PlannerImpl.java:336)
at
org.apache.beam.sdk.extensions.sql.impl.BeamQueryPlanner.convertToBeamRel(BeamQueryPlanner.java:135)

I feel like I'm missing something obvious. What is expected to happen when
a rule results in a composite collation trait?

If I remove CalcRemoveRule then everything is fine. But that seems like a
silly thing to have to do. And anyhow we also have a JDBC driver using
Avatica that (apparently?) has the rule added by the framework.

Kenn