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 1ljXKi-0001YE-RG for pgsql-bugs@arkaria.postgresql.org; Thu, 20 May 2021 01:18:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ljXKg-0002xu-Iu for pgsql-bugs@arkaria.postgresql.org; Thu, 20 May 2021 01:18:38 +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 1ljXKf-0002xm-P1 for pgsql-bugs@lists.postgresql.org; Thu, 20 May 2021 01:18:37 +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 1ljXKZ-0004lS-KZ for pgsql-bugs@lists.postgresql.org; Thu, 20 May 2021 01:18:36 +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 14K1ITSW3568086; Wed, 19 May 2021 21:18:29 -0400 From: Tom Lane To: "David G. Johnston" cc: Vitaly Ustinov , PostgreSQL mailing lists , Peter Eisentraut Subject: Re: Generated column is not updated (Postgres 13) In-reply-to: References: <3513055.1621461801@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Wed, 19 May 2021 18:02:39 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3568084.1621473509.1@sss.pgh.pa.us> Date: Wed, 19 May 2021 21:18:29 -0400 Message-ID: <3568085.1621473509@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > FWIW I can definitely see where the OP is coming from with this - the > expression at first blush, if one assumes PostgreSQL can handle the > nuances, seems like a perfectly reasonable semantic way to express the > programmer's desire. Combined with the fact it used to work makes me want > to lean toward keeping it working even if it takes come code hackery. I dunno, I think it "used to work" only for exceedingly small values of "work". For me, the given test case hits the same assertion failure in all versions back to v12, which is unsurprising because the code in ATRewriteTable is about the same. Also, considering only the table-rewrite code path is a mistake. The fundamental problem here is that the behavior is ill-defined and necessarily implementation-dependent; which makes it likely that other code paths behave inconsistently with ALTER TABLE ADD COLUMN. regards, tom lane