Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t14zA-00Ed6K-6P for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Oct 2024 14:26:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t14z8-004AwF-0r for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Oct 2024 14:26:46 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t14z7-004Aw6-O0 for pgsql-bugs@lists.postgresql.org; Wed, 16 Oct 2024 14:26:46 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t14z5-001MuP-Oo for pgsql-bugs@lists.postgresql.org; Wed, 16 Oct 2024 14:26:45 +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 49GEQdbd071061; Wed, 16 Oct 2024 10:26:39 -0400 From: Tom Lane To: Amit Langote cc: Tender Wang , Michael Paquier , exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18657: Using JSON_OBJECTAGG with volatile function leads to segfault In-reply-to: References: <18657-1b90ccce2b16bdb8@postgresql.org> Comments: In-reply-to Amit Langote message dated "Wed, 16 Oct 2024 21:00:19 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71059.1729088799.1@sss.pgh.pa.us> Date: Wed, 16 Oct 2024 10:26:39 -0400 Message-ID: <71060.1729088799@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Amit Langote writes: > Also, it might be better to leave a comment where the commit is > removing code, as follows: > - if (WALK(jve->raw_expr)) > - return true; > + /* Ignore raw_expr because it's not relevant at runtime. */ Would it be better for parse analysis to explicitly NULL out this field once it's done looking at it? Carrying unmaintained pieces of an expression tree around seems both inefficient and prone to future failures of this same ilk. The further the raw_expr gets out of step with current reality, the worse the hazards. regards, tom lane