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