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 1ruVaz-005q2u-DY for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 10:54:25 +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 1ruVax-000xOI-IF for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Apr 2024 10:54:23 +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 1ruVax-000xOA-5q for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 10:54:23 +0000 Received: from wfout8-smtp.messagingengine.com ([64.147.123.151]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ruVau-000BId-7G for pgsql-hackers@lists.postgresql.org; Wed, 10 Apr 2024 10:54:22 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id BDAA31C000F7; Wed, 10 Apr 2024 06:54:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 10 Apr 2024 06:54:17 -0400 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-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1712746456; x= 1712832856; bh=YLyf932NuDuHk7Iyno6fqLV3Rcfw12RlkSCwBOTHH2c=; b=b /xHIFaDSCH3qSHAlrw0YfSW1obt6xUjbUPS0FOmzi3XBwHu96J4neroPrFzg/uIr 3H4/l1pVJkpRpLFuQesqGX8To5+G9o8ri/uph5OZv5ckpumgXE1xwS0YlOZZZaLB cu9nkJCjW1FsN42fGL7icbBX0EhNgIuxCwWndIa/sYE6tA8FO79qoj/We/gp89Cv 14uDlXXn0N/flY0rb4SGOwh/VLG88F/wV69IKlKENpVYvvzm5frsji+BmdZuTvjg rvRlogYTT3A1U3JFd+Tk3doPLaPeQx8HBJ7bil4ohXB6HpJIv57dxPVKqeEJwZLM R3LW1pXEFYQCSTO87oJEA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudehiedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepvdektdffudfftdffffehfffhjeejhffgieeuueekjeek fffgudffhfduffffueevnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 10 Apr 2024 06:54:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1712746453; bh=0cOq3SfejsuIxcURzfK6MermQWWH21yMigrzwhLxV/A=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=QKsGVMIbmidCYIw/qIgDcaQ2birjJ4rPsWaOb0MREaizG0qSWTkvk2loZ18r985s4 hdRnr+/w0EcZdeFlzSBGQi1L+jAPB1Lx5xS8CcpxWAPKrp9nm86EqvL4BIhXtodV4p 2BOhVQpa9NFDfaGBOpt4m3XDAO4WKEfSkzJYR3DlN1jnnyendykKnwl5VBXYPvOph7 GFFE01zGaZQRRcQn1pVY9amBC7FzjOA0Bcgg5gSN8NTYoSSbLrp4mbQUkG0o7pLR+h 44YlkDo+bKRWWtWX/wdH2cvqzODAfkR3TRob6BcR33RoUEvIM0uknukSx7y0R2tdCO gIzfiIVDd8hcw== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 415BD385; Wed, 10 Apr 2024 12:54:13 +0200 (CEST) Date: Wed, 10 Apr 2024 12:54:13 +0200 From: Alvaro Herrera To: Tender Wang Cc: jian he , PostgreSQL Hackers Subject: Re: Can't find not null constraint, but \d+ shows that Message-ID: <202404101054.c2qhyi62by5n@alvherre.pgsql> 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 On 2024-Apr-10, Tender Wang wrote: > Yeah, it should fail as before, because c0 is primary key. > In master, although c0's pg_attribute.attnotnull is still true, but its > not-null constraint has been deleted > in dropconstraint_internal(). Yeah, the problem here is that we need to do the checks whenever the constraints are dropped, either directly or indirectly ... but we cannot do them in RemoveConstraintById, because if you elog(ERROR) there, it won't let you use DROP TABLE (which will also arrive at RemoveConstraintById): 55490 17devel 2220048=# drop table notnull_tbl2; ERROR: column "c0" of relation "notnull_tbl2" is an identity column ... which is of course kinda ridiculous, so this is not a viable alternative. The problem is that RemoveConstraintById doesn't have sufficient context about the whole operation. Worse: it cannot feed its operations back into the alter table state. I had a thought yesterday about making the resets of attnotnull and the tests for replica identity and PKs to a separate ALTER TABLE pass, independent of RemoveConstraintById (which would continue to be responsible only for dropping the catalog row, as currently). This may make the whole thing simpler. I'm on it. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Hay que recordar que la existencia en el cosmos, y particularmente la elaboración de civilizaciones dentro de él no son, por desgracia, nada idílicas" (Ijon Tichy)