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