Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18634: Wrong varnullingrels with merge ... when not matched by source
Date: 2024-09-28 00:39:53
Message-ID: CAMbWs4-OGaVXXBYmk41WtQQyLaaPS6WJ5KqrhJBAdpED-MOdbA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Sep 27, 2024 at 11:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?

I have the same concern. I think we should NOT mark the vars in
mergeJoinCondition as nullable, as mergeJoinCondition acts as join
quals rather than filter quals at that outer join. Instead, we should
mark them nullable when they are pulled out and ready to be added to
the targetlist, if they are really needed in the targetlist.

Thanks
Richard

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Laurenz Albe 2024-09-27 18:00:30 Re: BUG #18638: PANIC: could not open file "pg_logical/snapshots/B6-9EE5B820.snap": Permission denied