| 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: | Whole Thread | Raw Message | 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 |