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.96) (envelope-from ) id 1wIiIe-008PZJ-0L for pgsql-hackers@arkaria.postgresql.org; Fri, 01 May 2026 07:28:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wIiIb-00AK2u-2k for pgsql-hackers@arkaria.postgresql.org; Fri, 01 May 2026 07:28:33 +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.96) (envelope-from ) id 1wIiIb-00AK2h-1o for pgsql-hackers@lists.postgresql.org; Fri, 01 May 2026 07:28:33 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wIiIY-00000004DP7-3HcE for pgsql-hackers@lists.postgresql.org; Fri, 01 May 2026 07:28:32 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 9FEF85AA2E2 for ; Fri, 01 May 2026 09:28:29 +0200 (CEST) Received: from s980.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 918805ABB08; Fri, 01 May 2026 09:28:29 +0200 (CEST) Received: from localhost (unknown [172.22.191.5]) by s980.loopia.se (Postfix) with ESMTP id 8F3DB2201651; Fri, 01 May 2026 09:28:29 +0200 (CEST) X-Virus-Scanned: amavis at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1] autolearn=disabled Authentication-Results: s471.loopia.se (amavis); dkim=pass (2048-bit key) header.d=proxel.se Received: from s981.loopia.se ([172.22.191.6]) by localhost (s471.loopia.se [172.22.190.35]) (amavis, port 10024) with LMTP id jll4sLGIfP21; Fri, 1 May 2026 09:28:29 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: andreas@proxel.se X-Loopia-Originating-IP: 147.28.75.140 Received: from [192.168.0.186] (customer-147-28-75-140.stosn.net [147.28.75.140]) (Authenticated sender: andreas@proxel.se) by s981.loopia.se (Postfix) with ESMTPSA id 10D7322B1682; Fri, 01 May 2026 09:28:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proxel.se; s=loopiadkim1707418970; t=1777620509; bh=76nd26YZhpSPXMlQv43ntzDp+ZB6NaR4xwJeTjmiMiU=; h=Date:Subject:To:References:From:In-Reply-To; b=IQWP2uoP6YJcV22awewq5ygRqu4XuXymRld1vVNsqg42EktUu0gw4hGNbsfMP34Wc LE6467CsoOm6I7qNkfbI3D1H8w5sdxPclr8jJ+qcAafUfh/+c8VpmcWJfrY65L9Mpe Ngd2yvBedCQwMaxGOPs/dDYDcs11TkaMIn+qBsW2rdx2Qk0ctBNLWmEIypWea7vIe/ fHfupbNHEIAuFrpaur+gE9BIp4L3aBzH3Vmx6BzuNv7NrVVIfl0qL5xsZDm6w+fchX 4U+npNuse2tR+WjPaex08lm3MPESVuBurcsHtRHQL5CQ9En72wc13qs0YFSrjjPLMP Qcq7wcls4Piog== Message-ID: <49471fc0-5f07-4ed4-b33c-fc634aa301ef@proxel.se> Date: Fri, 1 May 2026 09:28:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fix pg_dump emitting OVERRIDING SYSTEM VALUE for tables with dropped identity columns To: William Bernbaum , "pgsql-hackers@lists.postgresql.org" References: Content-Language: en-US From: Andreas Karlsson In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/18/26 01:29, William Bernbaum wrote: > Hey hackers, > > I’ve encountered a small issue in pg_dump. > > It currently emits OVERRIDING SYSTEM VALUE in INSERTs for > > a table that doesn't have an identity column if it used to have > > a GENERATED ALWAYS AS IDENTITY column that was later dropped. > > [...] > > Patch attached. > > Thoughts? Nicely spotted and thanks for the patch! Please add it to the currently open commitfest (https://commitfest.postgresql.org/59/) so it is not lost. I have two pieces of feedback: 1. I think the code would be easier to read as if (!tbinfo->attisdropped[j]) tbinfo->needs_override = tbinfo->needs_override || tbinfo->attidentity[j] == ATTRIBUTE_IDENTITY_ALWAYS; or even if (tbinfo->attidentity[j] == ATTRIBUTE_IDENTITY_ALWAYS && !tbinfo->attisdropped[j]) tbinfo->needs_override = true; since then we do not get such a long line. 2. While I am not personally a fan of that file it would be more consistent if the new test was added as part of 002_pg_dump.pl if possible. Plus then it would mean that we would not need to create and tear down a PostgreSQL cluster. Andreas