From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: 857348270@qq.com,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17606: There is still some glitch in 3f7323cbb fixing
 failure of MULTIEXPR_SUBLINK
In-reply-to: 
 <CAMbWs48Qf=2ZL-d-0=9rYBZUPsp6FdLysuYULTtEvErwi3w3jg@mail.gmail.com>
References: <17606-e5c8ad18d31db96a@postgresql.org>
 <CAMbWs49A0FwQKq=_3pn6tRJqG5E_Y4uiUj9zAtuNbS0cTMYZ_A@mail.gmail.com>
 <CAMbWs48Qf=2ZL-d-0=9rYBZUPsp6FdLysuYULTtEvErwi3w3jg@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Mon, 05 Sep 2022 22:48:02 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2435362.1662393106.1@sss.pgh.pa.us>
Date: Mon, 05 Sep 2022 11:51:46 -0400
Message-ID: <2435363.1662393106@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2435363.1662393106%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Mon, Sep 5, 2022 at 10:25 PM Richard Guo <guofenglinux@gmail.com> wrote:
>> On Mon, Sep 5, 2022 at 3:33 PM PG Bug reporting form <
>> noreply@postgresql.org> wrote:
>>> 3f7323cbb regenerates its Param for each SubPlan by traversing the
>>> targetlist. But ignore one point: initplan is not in targetlist.
>>> This will result in a failed assertion, or an error like "unexpected
>>> PARAM_MULTIEXPR ID: 131074"

>> Since initplan SubPlans do not have args lists, I think it's OK for them
>> to share output parameters. So maybe we do not need to do the
>> SS_make_multiexprs_unique trick for initplan SubPlans?

Yeah, I agree.  The initial loop will do nothing anyway since the initplan
will no longer have a SubPlan in the tlist.  The problem is to get the
second loop to not adjust the numbers of the associated output Params.

> If I consider it correctly, can we fix the initplan SubPlan issue simply
> as below?

No, that'll malfunction if there's a mix of initplan and subplan
MULTIEXPRs.  I think we're going to have to bite the bullet and find a way
to discover the SubLinkIds of the non-initplan MULTIEXPRs, so that the
second loop can identify which Params to change and which not to.

AFAIR that info's no longer available by the time we get here, so
I imagine that a fix will require recording some more data during
SubLink-to-SubPlan conversion.

I'm sure glad that this isn't stuff we're going to need to carry
into the future...

			regards, tom lane