Re: Wrong results from an antijoin - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Wrong results from an antijoin
Date
Msg-id 225892.1791734192@sss.pgh.pa.us
Whole thread
In response to Re: Wrong results from an antijoin  (Richard Guo <guofenglinux@gmail.com>)
List pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes:
> On Fri, Oct 9, 2026 at 12:21 PM Richard Guo <guofenglinux@gmail.com> wrote:
>> So I think a more principled way is to give the antijoin a relid, just
>> like an antijoin reduced from a left join has, so that we can leverage
>> the well-established outer-join relid machinery to keep quals above
>> it.

+1

> Here is the patch I end up with.

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

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: REPACK: warn about skipping foreign partitions
Next
From: Greg Burd
Date:
Subject: Re: Let an ordering index scan hand its ORDER BY value to the target list