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 1wQ728-001IY1-0Z for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2026 17:18:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQ726-00AdKy-0Q for pgsql-hackers@arkaria.postgresql.org; Thu, 21 May 2026 17:18:07 +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.96) (envelope-from ) id 1wQ725-00AdKq-16 for pgsql-hackers@lists.postgresql.org; Thu, 21 May 2026 17:18:06 +0000 Received: from fout-b3-smtp.messagingengine.com ([202.12.124.146]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wQ721-00000000885-3ZGN for pgsql-hackers@lists.postgresql.org; Thu, 21 May 2026 17:18:02 +0000 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 974981D00112; Thu, 21 May 2026 13:18:00 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Thu, 21 May 2026 13:18:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm2; t=1779383880; x= 1779470280; bh=PyzfdXgzSqRN0o3Bcwxzq8bVwxObX8t5YB/Eai8hkbE=; b=m qhXzvhribWBvfM6kgmGGg8FT/zIh11nnUyylCrDHWJD7EwvOhUd2nFyqzri7Uw94 sZT0K/mCiOsRFLXGIhCvUgTnjukQEIQYZuXRjOL3o58tVQMjShRCxJm2U3ELOV+I ZcSvYZUjS4lBMCB8lwhEMEdyPdRl5tm0PCzrzURpuX+5R7RZw9b9Zyv14F9PZ1ti FIfdOvvVwY/GA76ORuejZRHZMxSNecj5xZ7a2Ld1rnrkMCDeM90zlJGdISNQDM27 7amRBiIMTySB1+2Jc8HODSkP8XWPdpJVsLQTzt4sN2yeRUC0wFalouRjoWSRwoQq JTbp5CosUKZdfm7RaUN1g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1779383880; x=1779470280; bh=P yzfdXgzSqRN0o3Bcwxzq8bVwxObX8t5YB/Eai8hkbE=; b=m02RbFGuOZOqBp30t lDZ3ltIIgHE9A7NRKJ0lQxMZ1NfKVQsOWGRuKx3aW1qN53HHJgTBZvcZA4mmyKr4 G5MOu8fAqEkmVeOyLHrd4tyFlZVT+biQox0BpH4PiV3JrtWybVAbShzxvYgbcDgS HcHsUPy+GZWLv24lIscViCXaIV6B0kzMKU9ALE9wxGSskIgIpyeBxF4q7thuaD5K QFUWKCklINxMxGa6AqtcAN6MB15GnxjtmkwUNryHLgX74eg4cAfmlmfQGTHr6EWM Xf81Nus/FC94taia5HrHI1JdeMhn7pU4sqPzmyonQWEvD6sT4E+QchDnsZB7BsgJ w/Bpw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgddugeektdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpedtvdekhefghfeuffeltdetgeeifffhteeiteeftddvffefhfeggeek heefgfejhfenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmpdhpohhsth hgrhdrvghsnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mheprghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvpdhnsggprhgtphhtthhopedvpd hmohguvgepshhmthhpohhuthdprhgtphhtthhopehrvghshhhkvghkihhrihhllhesghhm rghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehlihhsthhsrd hpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 21 May 2026 13:18:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1779383878; bh=FqQ7amd4sPXD5XMuMEUxxR77bjFVm3NiTarSSAOrtXI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=Rv4vScSDPofrLoO8smlW+jBvI2TbC9BDy4x3DaB4IedaI1Ghb2Bfq+88D2KjwHB+S cX4B2JsSy2E3Rz1B/ApD5bTcaVHs4+lUvJYpmUgQ7FUnvh4+71qujeLc3f0Fvv9k0N u+WInrt515TJE3beEd3mZaRzbJHk7PWJptW0eXn8Q18Cf/Lc9UZ31I/BQFcrrWe92Z 7WdJ7oZv22bm4lcedJteWMOqw9teg+EnqFfS6y/sOcY92h38cJKipg5kspkcL+4dO7 p4Ggj0PzK8GsguY/abn7PFAlLSqMiZE9RyBOFtRq8YxBvIWjpFMehkZI7pSCxQeO31 F3wugvyv04Cvw== Received: by ida.kurilemu.internal (Postfix, from userid 1000) id 9BE6EB0415C; Thu, 21 May 2026 10:17:58 -0700 (PDT) Date: Thu, 21 May 2026 10:17:58 -0700 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Kirill Reshke Cc: PostgreSQL Hackers Subject: Re: Pg upgrade bug with NOT NULL NOT VALID Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-May-21, Kirill Reshke wrote: > On pg 17: > > create table t(i int not null); > alter table t add constraint t_i_not_null check((i is not null)) not valid; > [...] Hmm, interesting :-( > I think we need to fix this in the spirit of [0]. I'm currently > thinking of choosing a less obvious name for NOT NULL constraint that > is created during CREATE TABLE processing. Is that a good way to > address this? I don't think so, because any name you choose mechanically can be chosen by the user for their check constraint, so you will be making the constraint name significantly worse in all cases while not giving any hard assurances that you've fully fixed the problem, just moved it around. I see two alternatives. One is to have pg_dump --binary-upgrade choose a constraint name for the not-null with full knowledge of all other constraint names, so that we know to generate a non conflicting one. I suspect this is not easy to code. The other is much simpler: make pg_upgrade -c warn you about the check constraint name so that you know to rename it before the upgrade. This should be fairly trivial. I think the only somewhat ugly thing about this is that we'd need to match ChooseConstraintName more closely in the cases of overly long table and column names. The current algorithm we have to generate constraint names on the pg_dump side for not-null constraints is naive because it doesn't matter if it gets it slightly wrong in those border cases; but in this case it would matter. Thanks, -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "You're _really_ hosed if the person doing the hiring doesn't understand relational systems: you end up with a whole raft of programmers, none of whom has had a Date with the clue stick." (Andrew Sullivan) https://postgr.es/m/20050809113420.GD2768@phlogiston.dyndns.org