Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dean Rasheed <dean.a.rasheed@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-09-27T15:43:21Z
Lists: pgsql-bugs
Dean Rasheed <dean.a.rasheed@gmail.com> writes: > On Fri, 27 Sept 2024 at 13:52, Richard Guo <guofenglinux@gmail.com> wrote: >> I think we can check the jointype of the join between the target and >> the source relation when adding the vars in mergeJoinCondition. If it >> is JOIN_LEFT, we mark the vars that belong to source as nullable by >> this join. > Another option is to do it in transform_MERGE_to_join(). That feels > safer, because the jointree might have been modified by the time we > reach preprocess_targetlist(). Yeah, I think it's critical that these Vars be already correctly marked before we engage in all the slicing-and-dicing that prepjointree et al will do. As an example, it seems not impossible for join removal to make wrong decisions if they aren't. > Something like the attached. Could use some comments ... but actually, now I'm confused about why any of this is the right thing at all: + * Similarly, any non-target Vars in the join condition will be added to + * the targetlist by preprocess_targetlist(), and so must be marked as + * nullable by the join, for LEFT and FULL joins. Why do we need these Vars in the tlist? If they're for re-evaluating the join condition, isn't the already-nulled form of them the wrong thing? regards, tom lane
Commits
-
Fix wrong varnullingrels error for MERGE WHEN NOT MATCHED BY SOURCE.
- 259a0a99fe3d 18.0 landed
- 34ae54af92e0 17.1 landed
-
Fix incorrect non-strict join recheck in MERGE WHEN NOT MATCHED BY SOURCE.
- dddb5640c6d3 18.0 landed
- d7d297f84496 17.1 landed