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
Date: Mon, 05 Sep 2022 12:18:04 -0400
Message-ID: <2439275.1662394684@sss.pgh.pa.us> (raw)
In-Reply-To: <2435363.1662393106@sss.pgh.pa.us>
References: <17606-e5c8ad18d31db96a@postgresql.org>
<CAMbWs49A0FwQKq=_3pn6tRJqG5E_Y4uiUj9zAtuNbS0cTMYZ_A@mail.gmail.com>
<CAMbWs48Qf=2ZL-d-0=9rYBZUPsp6FdLysuYULTtEvErwi3w3jg@mail.gmail.com>
<2435363.1662393106@sss.pgh.pa.us>
I wrote:
> 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.
After contemplating that for awhile, by far the least painful way
seems to be to add the subLinkId to struct SubPlan. We can get
away with that in the back branches as long as we add it at the
end, since SubPlans don't get recorded in the catalogs.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
In-Reply-To: <2439275.1662394684@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox