Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source
От | Tom Lane |
---|---|
Тема | Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source |
Дата | |
Msg-id | 491922.1727451801@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18634: Wrong varnullingrels with merge ... when not matched by source (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source
|
Список | 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
В списке pgsql-bugs по дате отправления: