From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | sully(at)msully(dot)net, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery |
Date: | 2022-05-12 14:51:22 |
Message-ID: | 327116.1652367082@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Thu, May 12, 2022 at 7:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Lepikhov | 2022-05-13 06:56:43 | Negative value of numGroups |
Previous Message | Richard Guo | 2022-05-12 07:51:01 | Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery |