Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
От | Tom Lane |
---|---|
Тема | Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK |
Дата | |
Msg-id | 2439275.1662394684@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK
Re: BUG #17606: There is still some glitch in 3f7323cbb fixing failure of MULTIEXPR_SUBLINK |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: