Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery
От | Tom Lane |
---|---|
Тема | Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery |
Дата | |
Msg-id | 327116.1652367082@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery (Richard Guo <guofenglinux@gmail.com>) |
Список | pgsql-bugs |
Richard Guo <guofenglinux@gmail.com> writes: > On Thu, May 12, 2022 at 7:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> What became of SubPlan 1? Maybe this is fine but it looks a little >> shaky. We should at least run down why that's happening and make >> sure we're not leaving dangling pointers anywhere. > I did some debug on this. The 'SubPlan 1' is not explained because its > SubPlanState is not created and added to AggState->subPlan. Yeah, concur: there are two subplans in the plan tree, so no dangling pointers. > Not sure if this is fine or not. It seems cosmetic. We could somehow force initialization of the GroupingFunc's argument tree, but that would just be wasted cycles in non-EXPLAIN cases, and it seems semantically wrong anyway given that evaluation of the argument is not supposed to happen. (Right now that's hypothetical, but what if ExecInitExpr started to pre-evaluate some things?) Given the history of this thing, maybe we will find something that depends on such initialization happening. But without evidence for that I'm not inclined to add code for it. I'll run with the patch as you suggested. regards, tom lane
В списке pgsql-bugs по дате отправления: