SteveStevenpoor commented on code in PR #26702:
URL: https://github.com/apache/flink/pull/26702#discussion_r2158232920
##########
flink-table/flink-table-planner/src/test/java/org/apache/flink/table/planner/plan/stream/sql/MultiJoinTest.java:
##########
@@ -154,6 +163,16 @@ void testFourWayComplexJoinRelPlan() {
+ "LEFT JOIN Shipments s ON p.user_id_2 =
s.user_id_3");
}
+ @Test
+ void testFourWayJoinNoCJKRelPlan() {
+ util.verifyRelPlan(
+ "SELECT u.user_id_0, u.name, o.order_id, p.payment_id,
s.location "
+ + "FROM Users u "
+ + "LEFT JOIN Orders o ON u.user_id_0 = o.user_id_1 "
+ + "INNER JOIN Payments p ON u.user_id_0 = p.user_id_2 "
+ + "LEFT JOIN Shipments s ON p.payment_id =
s.user_id_3");
+ }
+
Review Comment:
> Ah, I see. In general, I'm pretty sure we don't. I think this is relevant
for reordering. The rule assumes reorder should've been done earlier and I
think we could drop it. Could you think of other consequences?
If being honest, in my version of FlinkJoinToMultiJoinRule I dropped it :)
If we both don't see consequences, maybe I should drop it for now? Or we can
ask somebody if they know.
--
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]
