Re: Wrong results from an antijoin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong results from an antijoin
Date: 2026-10-13 19:40:50
Message-ID: 741078.1791920450@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> 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.

v2 works for me.

> 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.)

Fair enough on both points. convert_ANY_sublink_to_join has been like
that for a long time and hasn't caused trouble, so I'm not in a huge
hurry to change it.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zsolt Parragi 2026-10-13 19:43:41 Re: find_all_inheritors() with NoLock fails on concurrently dropped sub-partitions
Previous Message Tom Lane 2026-10-13 19:36:51 Re: Deprecation warnings on Rocky 10.2 with current dev branch