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
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 |