Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Mon, Sep 5, 2022 at 10:25 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> On Mon, Sep 5, 2022 at 3:33 PM PG Bug reporting form <
>> noreply(at)postgresql(dot)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