Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npAA4-0002XX-IP for pgsql-bugs@arkaria.postgresql.org; Thu, 12 May 2022 14:51:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1npAA3-0001Zd-G9 for pgsql-bugs@arkaria.postgresql.org; Thu, 12 May 2022 14:51:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npAA3-0001W8-7T for pgsql-bugs@lists.postgresql.org; Thu, 12 May 2022 14:51:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npAA0-00062L-T9 for pgsql-bugs@lists.postgresql.org; Thu, 12 May 2022 14:51:26 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 24CEpMuT327117; Thu, 12 May 2022 10:51:22 -0400 From: Tom Lane To: Richard Guo cc: sully@msully.net, PostgreSQL mailing lists Subject: Re: BUG #17479: "plan should not reference subplan's variable" when calling `grouping` on result of subquery In-reply-to: References: <17479-6260deceaf0ad304@postgresql.org> <218738.1652310685@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Thu, 12 May 2022 15:51:01 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <327115.1652367082.1@sss.pgh.pa.us> Date: Thu, 12 May 2022 10:51:22 -0400 Message-ID: <327116.1652367082@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Thu, May 12, 2022 at 7:11 AM Tom Lane 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