Re: Wrong results from an antijoin

On Mon, Oct 12, 2026 at 12:56 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm on board with this solution, and the only real quibble I have with
> this patch is that add_antijoin_rte() uses addRangeTableEntryForJoin.
> I think that's a substantial abuse of the parser and it's lucky that
> it works at all. I realize that convert_ANY_sublink_to_join does
> something comparable, but addRangeTableEntryForSubquery feels less
> dependent on the state of the parse data structures. In any case
> it might be cleaner in the long run for both of those places to build
> a RangeTblEntry for themselves (or maybe they could share a function
> that does that?)

Thanks for looking! Yeah, I chose to use addRangeTableEntryForJoin in
add_antijoin_rte() because I noticed that convert_ANY_sublink_to_join
is using addRangeTableEntryForSubquery. But I agree that this is
abuse of the parser and we should avoid that.

In v2, I updated add_antijoin_rte() to build the RTE by hand, much as
transform_MERGE_to_join() does for its join RTE.

I left convert_ANY_sublink_to_join alone in this patch, since the fix
needs to go back to v16 and that change isn't needed for it. We can
do it as a follow-up cleanup on master.

(I'm not sure about a shared function though. The subquery RTE needs
the subquery, the lateral flag and column names taken from its
targetlist, while the join RTE needs nothing but the jointype, so
about all the two have in common is the makeNode and the lappend.)

- Richard