viirya commented on code in PR #24336: URL: https://github.com/apache/datafusion/pull/24336#discussion_r3778534559
########## datafusion/sqllogictest/test_files/pwmj.slt: ########## @@ -342,5 +342,22 @@ ORDER BY 1,2; 1 3 2 3 +# RIGHT JOIN: every right row must be emitted, including one whose join key is +# NULL. A NULL key never matches (NullEqualsNothing), so t2.id = NULL is +# unmatched and must appear as (NULL, NULL). Regression test: the streamed-side +# NULL rows are skipped by the match scan and were previously dropped instead of +# being reported as unmatched. +query II +SELECT t1.id AS left_id, t2.id AS right_id Review Comment: Good question — the fix path is `Right | Full`, so it covers `FULL JOIN` too. I've added a `FULL JOIN` test in the latest commit. I couldn't reuse the `null_join_*` tables for it: on this branch's base, a `FULL JOIN` over those still drops the unmatched **left** NULL-keyed row (`t1.id = NULL`). That's a *separate* pre-existing bug — the classic Left/Full unmatched-row drop, which #23870 fixes but `main` doesn't have yet — unrelated to the right-side NULL fix here, so a `FULL JOIN` on `null_join_*` would fail on this base for that other reason. To keep the test focused on what this PR fixes (the unmatched right-side NULL row), the added `FULL JOIN` case uses data where every left row matches, so only the right-NULL emission is exercised. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
