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 1uWGDZ-00BE0i-IS for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Jun 2025 15:14:49 +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 1uWGDX-000OgL-JF for pgsql-bugs@arkaria.postgresql.org; Mon, 30 Jun 2025 15:14:48 +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 1uWGDX-000OgC-AZ for pgsql-bugs@lists.postgresql.org; Mon, 30 Jun 2025 15:14:47 +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.96) (envelope-from ) id 1uWGDV-004vRW-2u for pgsql-bugs@lists.postgresql.org; Mon, 30 Jun 2025 15:14:47 +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 55UFEhPx2828230; Mon, 30 Jun 2025 11:14:43 -0400 From: Tom Lane To: jian he cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18970: Atempt to alter type of table column used in row type with check leads to assertion failure In-reply-to: References: <18970-a7d1cfe1f8d5d8d9@postgresql.org> <2482012.1751216513@sss.pgh.pa.us> <2537374.1751218360@sss.pgh.pa.us> <2682232.1751250210@sss.pgh.pa.us> Comments: In-reply-to jian he message dated "Mon, 30 Jun 2025 14:04:25 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2828228.1751296483.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Jun 2025 11:14:43 -0400 Message-ID: <2828229.1751296483@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk jian he writes: > SET EXPRESSION both can have this issue. > so i also add more test cases for stored/virtual generated columns. This patch is a lot larger than I was expecting, and I think it's misguided. You argue that + * Changing a virtual generated column's expression is akin to alteri= ng its + * type, requiring a call to find_composite_type_dependencies to chec= k if + * the virtual generated column is used in any table. + * Therefore we need add this defval to tab->newvals for virtual gene= rated + * column too, so Phase3 will call find_composite_type_dependencies. but I think that is in fact wrong. The implementation restriction we have is that we lack code to run around and physically change the stored values of columns that are not top-level table columns. However, in the case of a virtual column we don't need to change anything about the storage: once we've fixed the catalog metadata, we're done. So I'm not seeing the need to add all this stuff other than the additional locking calls. regards, tom lane