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 1t1c4q-00H4KA-AU for pgsql-bugs@arkaria.postgresql.org; Fri, 18 Oct 2024 01:46:52 +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 1t1c4o-00DSe4-Gp for pgsql-bugs@arkaria.postgresql.org; Fri, 18 Oct 2024 01:46:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1c4o-00DSdw-8G for pgsql-bugs@lists.postgresql.org; Fri, 18 Oct 2024 01:46:50 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t1c4l-001SYU-UM for pgsql-bugs@lists.postgresql.org; Fri, 18 Oct 2024 01:46:49 +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 49I1kj0q765960; Thu, 17 Oct 2024 21:46:45 -0400 From: Tom Lane To: Tender Wang cc: Amit Langote , 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> <71060.1729088799@sss.pgh.pa.us> <508107.1729126612@sss.pgh.pa.us> <569213.1729138329@sss.pgh.pa.us> <711200.1729197017@sss.pgh.pa.us> Comments: In-reply-to Tender Wang message dated "Fri, 18 Oct 2024 09:34:33 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <765958.1729216005.1@sss.pgh.pa.us> Date: Thu, 17 Oct 2024 21:46:45 -0400 Message-ID: <765959.1729216005@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tender Wang writes: >> In any case, whatever we do in master, you can't "simply revert" >> b6e1157e7 in released branches. It changed the way JsonValueExpr is >> represented in stored rules, and you don't get to undo that midstream. > Sorry, I can't fully understand what you said above. What's the stored > rule? > And "you don't get to undo that midstream." What is the Scenario that we > get to undo? If somebody has created a view that contains a JsonValueExpr, then the post-parse-analysis query tree for that is stored in pg_rewrite. A minor version update can't change that query tree. So basically, once a major version has shipped, its parse-analysis output format is frozen. We can redefine that sort of thing in major releases, because either pg_upgrade or dump/reload will result in re-parsing view definitions. But that doesn't happen in minor-version updates. This restriction doesn't apply to planner output trees, since those don't have any lifespan longer than a session. That's how come it's okay to consider changing the behavior of eval_const_expressions. regards, tom lane