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-11 15:56:32
Message-ID: 225892.1791734192@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:
> On Fri, Oct 9, 2026 at 12:21 PM Richard Guo <guofenglinux(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Burd 2026-10-11 16:42:50 Re: Let an ordering index scan hand its ORDER BY value to the target list
Previous Message Fujii Masao 2026-10-11 15:48:21 Re: REPACK: warn about skipping foreign partitions