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

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-09-28 03:11:15 BUG #18640: Replica Sync Failure After Downtime in Patroni HA Setup Due to Missing WAL Segments
Previous Message PG Bug reporting form 2024-09-27 23:33:46 BUG #18639: Unexpected behavior with SET ROLE and CREATE ROLE interaction