From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Check SubPlan clause for nonnullable rels/Vars |
Date: | 2022-11-03 09:17:58 |
Message-ID: | CAMbWs4_e=oapGYPsc+_XEyq0z2oML9uhXQhxPw_RoQ284whpMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 3, 2022 at 4:26 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> * I don't believe you can prove anything from an ALL_SUBLINK SubPlan,
> because it will return true if the sub-query returns zero rows, no
> matter what the testexpr is. (Maybe if you could prove the sub-query
> does return a row, but I doubt it's worth going there.)
Thanks for pointing this out. You're right. I didn't consider the case
that the subplan produces zero rows. In this case ALL_SUBLINK will
always return true, and ANY_SUBLINK will always return false. That
makes ALL_SUBLINK not strict, and ANY_SUBLINK can be strict only at top
level.
* You need to explicitly check the subLinkType; as written this'll
> consider EXPR_SUBLINK and so on. I'm not really on board with
> assuming that nothing bad will happen with sublink types other than
> the ones the code is expecting.
>
Yes, I need to check for ANY_SUBLINK and ROWCOMPARE_SUBLINK here. The
testexpr is only meaningful for ALL/ANY/ROWCOMPARE, and ALL_SUBLINK has
been proven not strict.
* It's not apparent to me that it's okay to pass down "top_level"
> rather than "false". Maybe it's all right, but it could do with
> a comment.
The 'top_level' param is one point that I'm not very confident about.
I've added comments in the v2 patch.
Thanks for reviewing this patch!
Thanks
Richard
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Check-SubPlan-clause-for-nonnullable-rels-Vars.patch | application/octet-stream | 5.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lawrence Barwick | 2022-11-03 09:29:44 | Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15) |
Previous Message | John Naylor | 2022-11-03 09:09:14 | Re: Prefetch the next tuple's memory during seqscans |