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 по дате отправления: