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 1nUJKU-0000e2-He for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Mar 2022 02:24:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nUJKQ-0005fB-IR for pgsql-bugs@arkaria.postgresql.org; Wed, 16 Mar 2022 02:23:58 +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 1nUJKQ-0005er-AU for pgsql-bugs@lists.postgresql.org; Wed, 16 Mar 2022 02:23:58 +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 1nUJKN-000282-SE for pgsql-bugs@lists.postgresql.org; Wed, 16 Mar 2022 02:23:57 +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 22G2Nhg7453335; Tue, 15 Mar 2022 22:23:43 -0400 From: Tom Lane To: Kevin Humphreys cc: Peter Eisentraut , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE In-reply-to: References: <17439-7df4421197e928f0@postgresql.org> <339142.1647369200@sss.pgh.pa.us> <412466.1647374777@sss.pgh.pa.us> <425437.1647379135@sss.pgh.pa.us> Comments: In-reply-to Kevin Humphreys message dated "Tue, 15 Mar 2022 21:46:35 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <453333.1647397423.1@sss.pgh.pa.us> Date: Tue, 15 Mar 2022 22:23:43 -0400 Message-ID: <453334.1647397423@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Kevin Humphreys writes: > Thanks for deep-diving into this Tom! I don't have any experience with the > internal workings of Postgres but if I am understanding correctly: > - This is definitely a bug and not intended or expected behavior and goes > against SQL specifications Looks like a bug to me. The aspect of this that a drop of a table column causes silent drop of dependent generated columns is clearly intentional, but AFAICS that's based on a misreading of the spec. I suspect that the fact that it carries over to other dependencies of the generation expression was just failure to consider that case. > - This is a non-trivial fix > - This is a fix that can not be back-ported to Postgres 13? > - This is a fix that can be made to Postgres 14? Yes, yes, no. I don't think we'd risk trying to change this for any released branch, because redefining catalog contents in existing installations carries all sorts of hazards. Given that it's been wrong since v12 and you're the first to complain, I judge that fixing it in released branches is not worth taking such risks for. We should definitely endeavor to get it fixed for v15 though. > Is there any recommendation you would have for mitigation besides not > dropping functions that may be used by generated columns? I don't see any good user-level workaround :-(. regards, tom lane