[minogin]

Jira: https://issues.apache.org/jira/browse/CALCITE-7902

Cause

VolcanoPlanner does not register transformation rules for PhysicalNode classes, so a physical rel never becomes the entry point of a TransformationRule. A rule call can still reach a physical rel while it matches the other operands. In VolcanoRuleCall.matchRecurse, the only check for transformation rules is that a rel has the same convention as the previously matched one.

JoinAssociateRule has operands Join(Join, RelNode). The RelNode operand matches an AbstractConverter with ENUMERABLE convention, which ExpandConversionRule creates. AbstractConverter is not a PhysicalNode, so it is an entry point. From there the match goes up to the parent EnumerableHashJoin and down to its input EnumerableHashJoin. All three have the ENUMERABLE convention, so the check passes, the rule fires on physical joins, and transformTo throws ... is a PhysicalNode, which is not allowed in JoinAssociateRule.

Fix

In matchRecurse, a TransformationRule now skips a rel that is a PhysicalNode, as well as one whose convention differs. This matches what VolcanoPlanner.addRule and onNewClass already do for entry points.

Test

PlannerTest#testJoinAssociateDoesNotMatchPhysicalJoin runs a three-table join through Volcano with JOIN_ASSOCIATE, ExpandConversionRule and the enumerable rules, including merge join. Without the fix it fails with the error from the issue.

VolcanoPlannerTest, PlannerTest, RelOptRulesTest, org.apache.calcite.plan.* and TopDownOptTest pass.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[mihaibudiu]

This may be fine, but the issue gives an example of a failing program.
Can you have a test with showing that the program now works?