On Mon, Oct 12, 2026 at 12:56 AM Tom Lane <[email protected]> wrote: > 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?)
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. 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.) - Richard
v2-0001-Give-antijoins-made-from-sublinks-a-relid.patch
Description: Binary data
