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 1soT4j-00BU6T-Rt for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2024 19:32:27 +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 1soT4j-006d14-8M for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2024 19:32:25 +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 1soT4i-006d0w-Sg for pgsql-hackers@lists.postgresql.org; Wed, 11 Sep 2024 19:32:24 +0000 Received: from fout8-smtp.messagingengine.com ([103.168.172.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 1soT4e-000hHP-JH for pgsql-hackers@lists.postgresql.org; Wed, 11 Sep 2024 19:32:24 +0000 Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfout.phl.internal (Postfix) with ESMTP id A1F9D13800DD; Wed, 11 Sep 2024 15:32:19 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Wed, 11 Sep 2024 15:32:19 -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=fm1; t=1726083139; x= 1726169539; bh=807vFKYURFsd0hHQ1+qUz48jJOGBEIwy8oI5lwSYKzY=; b=h Gg3AmhjzGyjqrVc+AUu6kEr3iTQkV86XY0dcilsIkXjT5yk+ZuCeKw+AaZ40vm58 MIKmy5JebtQTJI69uLDZFybxKUDqJ/9PSxjVy25Pvhy8Dm+sJt+o08dIK7IzLX6u QBNum4DmIMhQg+O+SuGShigHtGnhsho/aBMx3S5tCxMp6VSTVXU7S6joBU3kTwm6 ggYd0UXNZsWp7f8pPFzeVXmiwgKBIs9bissZmNx4vPNgM2PZGj1LilNfKfZQ2UE1 C2WcsBGQhhV+CqmCFeSNSteHnYRzpG7ty1j6Xcv9cABbH9fOAulOdMRRnmy/aFTe rZyBuIekCJyZ79Eim5iig== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudejuddgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdej necuhfhrohhmpeetlhhvrghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvh hhrdhnohdqihhprdhorhhgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheff hfejjefhgfeiueeukeejkeffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrh hprhhishgvuggsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrghdpnhgspg hrtghpthhtohepfedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhirghnrdhu nhhivhgvrhhsrghlihhthiesghhmrghilhdrtghomhdprhgtphhtthhopehtnhgurhifrg hnghesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehl ihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 11 Sep 2024 15:32:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alvh.no-ip.org; s=schmee; t=1726083136; bh=aDjG/2aGHvxYP0GzrdKQr/MThQGd5zK0U5NcjyS3Ny0=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=GzIH6TfNAcML8QT9RViKA8YydnHkoWz5kLEN3Uy5s/gO7S2Yr1epQl+tyJ6QpUlDO oiqQ/mWe3LKbC6Uy17QA+5t09Oemdx7LNiW6dFVsQBLEtL3klPBF+6niDmAE0QxLBm e/UZHq0lChTkobVkcp2HECdwucxiZ4fBYppEOitiQhuu+jjiTGlOCDnlnT86Ql359N qJGzvmHHN5hQng5bRMXeXYM5gjr1AIF4oeTZAGAFnjDbGkCj3iwDNai4PQufyhtOHE m4upjB4PHqY0ClhsBUqDEm+TwN4PygETw9R3PRIp8JXRfuTxNDYWOKtEGT3gaZMU4P 2z1mskS966UQg== Received: by schmee.alvh.no-ip.org (Postfix, from userid 1000) id 99E33D35; Wed, 11 Sep 2024 16:32:16 -0300 (-03) Date: Wed, 11 Sep 2024 21:32:16 +0200 From: Alvaro Herrera To: jian he Cc: Tender Wang , Pg Hackers Subject: Re: not null constraints, again Message-ID: <202409111932.pxovsxtwxaqu@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-Sep-11, jian he wrote: > On Wed, Sep 11, 2024 at 2:18 AM Alvaro Herrera wrote: > > > > Hello, here's a v2 of this patch. I have fixed --I think-- all the > > issues you and Tender Wang reported (unless I declined a fix in some > > previous email). > > > > + /* > + * The constraint must appear as inherited in children, so create a > + * modified constraint object to use. > + */ > + constr = copyObject(constr); > + constr->inhcount = 1; > > in ATAddCheckNNConstraint, we don't need the above copyObject call. > because at the beginning of ATAddCheckNNConstraint, we do > newcons = AddRelationNewConstraints(rel, NIL, > list_make1(copyObject(constr)), > recursing || is_readd, /* > allow_merge */ > !recursing, /* is_local */ > is_readd, /* is_internal */ > NULL); /* queryString not available > * here */ I'm disinclined to change this. The purpose of creating a copy at this point is to avoid modifying an object that doesn't belong to us. It doesn't really matter much that we have an additional copy anyway; this isn't in any way performance-critical or memory-intensive. > create table idxpart (a int) partition by range (a); > create table idxpart0 (like idxpart); > alter table idxpart0 add primary key (a); > alter table idxpart attach partition idxpart0 for values from (0) to (1000); > alter table idxpart add primary key (a); > > alter table idxpart0 DROP CONSTRAINT idxpart0_pkey; > alter table idxpart0 DROP CONSTRAINT idxpart0_a_not_null; > > First DROP CONSTRAINT failed as the doc said, > but the second success. > but the second DROP CONSTRAINT should fail? > Even if you drop success, idxpart0_a_not_null still exists. > it also conflicts with the pg_constraint I've quoted above. Hmm, this is because we allow a DROP CONSTRAINT to set conislocal from true to false. So the constraint isn't *actually* dropped. If you try the DROP CONSTRAINT a second time, you'll get an error then. Maybe I should change the order of checks here, so that we forbid doing the conislocal change; that would be more consistent with what we document. I'm undecided about this TBH -- maybe I should reword the documentation you cite in a different way. > transformTableLikeClause, expandTableLikeClause > can be further simplified when the relation don't have not-null as all like: > > /* > * Reproduce not-null constraints by copying them. This doesn't require > * any option to have been given. > */ > if (tupleDesc->constr && tupleDesc->constr->has_not_null) > { > lst = RelationGetNotNullConstraints(RelationGetRelid(relation), false); > cxt->nnconstraints = list_concat(cxt->nnconstraints, lst); > } True. > Also, seems AdjustNotNullInheritance never being called/used? Oh, right, I removed the last callsite recently. I'll remove the function, and rename AdjustNotNullInheritance1 to AdjustNotNullInheritance now that that name is free. Thanks for reviewing! I'll handle your other comment tomorrow. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/