[CALCITE-7514] MultiJoinOptimizeBushyRule throws AssertionError when a join condition references 3 or more factors

[sbroeder]

Jira Link

CALCITE-7514

Changes Proposed

MultiJoinOptimizeBushyRule crashes with an AssertionError when a
MultiJoin's join filters contain a condition that references anything
other than exactly two factors (e.g. a CASE expression spanning three
tables). Such conditions cannot be represented as binary join edges, so
passing them to createEdge produced an edge with
factors.cardinality() != 2, which violated assertions in the edge
comparator and the greedy ordering loop.

Fix: conditions that do not touch exactly two factors are separated
from the edge list before the greedy loop runs. After the join tree is
built, these conditions are remapped from the original MultiJoin field
positions to the output positions of the final join tree using
RexPermuteInputsShuttle, then applied as a LogicalFilter above the
join tree (before the reordering project). For inner joins this is
semantically equivalent to applying them as join predicates.

This also resolves two long-standing TODOs in the class Javadoc:

• "Join conditions that touch 3 factors." — fully handled.
• "Join conditions that touch 1 factor." — handled defensively (no
  crash, correct result); optimal push-down to the scan is left as a
  future improvement.

Reproduction: the following query previously threw AssertionError:

SELECT e1.ename
FROM emp e1, dept d, emp e2
WHERE e1.deptno = d.deptno
  AND e2.deptno = d.deptno
  AND d.deptno = CASE WHEN e1.sal > 1000 THEN e2.empno ELSE e1.empno END
A new test testMultiJoinOptimizeBushyThreeFactorCondition in
RelOptRulesTest covers this case.

[mihaibudiu]

If there are no other comments, let's merge this.
Please squash the commits to a single one.

[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