Re: Check SubPlan clause for nonnullable rels/Vars

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

In response to

Responses

Browse pgsql-hackers by date

  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