minogin opened a new pull request, #5372: URL: https://github.com/apache/calcite/pull/5372
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](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
