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.98.2) (envelope-from ) id 1x9koD-00000002Ct3-3aTt for pgsql-bugs@arkaria.postgresql.org; Thu, 24 Sep 2026 14:52:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1x9koD-0000000Cqip-0SBK for pgsql-bugs@arkaria.postgresql.org; Thu, 24 Sep 2026 14:52:25 +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.98.2) (envelope-from ) id 1x9k8W-0000000COrE-1GN6 for pgsql-bugs@lists.postgresql.org; Thu, 24 Sep 2026 14:09:20 +0000 Received: from mail-244121.protonmail.ch ([109.224.244.121]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x9k8R-000000012ZW-3xaa for pgsql-bugs@lists.postgresql.org; Thu, 24 Sep 2026 14:09:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1790258953; x=1790518153; bh=5Us3nr6A0Pyh5Zf4PiC3XrZQ9qOK2Y5BX3SoavD6S3Y=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=ji817Hf4ethFGiXnCGsRs9cMUmhHDlXX+JOlHaTW7GrNl2bdohGFN+pALlgqbHcRs zYC1KvjW8lbCLgevHsaT0fxuTb9XoVZwLivpIvW1h6ix7ZoEG8oH91wVRuVX8nvI5b A6MGHtSPDp/+K+Xg+1qb6VA6i4P6pVjXpGThuigUOjYb7Qdm4BdLTHSo8NkMw+KkCa /21qS3trFdNsLfDMUegj7G0XtFBN1eCJG4RVAXKqtIoL2RQQzMMNP8W+9bTAPm+pr9 4vtzRUKu5Z4MMxzIuVLBTlNmPoAxt2nBYq9q4imvwXaHwYTJUAeC3G1d4TxSBrDT9t fxZEHxpWSGUUw== Date: Thu, 24 Sep 2026 14:09:09 +0000 To: Manuel Reyes Bravo , Fujii Masao From: Ludvig Janiuk Cc: pgsql-bugs@lists.postgresql.org Subject: Re: 42P16 error when dropping and adding column Message-ID: <9221c3eb-2b4e-42f7-899c-61b59482a38b@proton.me> In-Reply-To: References: <0a9b4c44-cdff-4ec8-a8fb-b3a8b59e9ba9@proton.me> Feedback-ID: 90025008:user:proton X-Pm-Message-ID: 244bb57afe0871dc57919a799e06831641e8ed7c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thank you both for responding so quickly and reviewing my report. I'm not familiar with the Postgres bug lifecycle - is there anything=20 else I need to do? File a formal bug in some tracker? Or has that=20 already happened? Best regards, Ludvig Janiuk On 2026-09-17 17:01, Manuel Reyes Bravo wrote: > Hi Fujii-san, > > Fujii Masao wrote: >> This issue seems to happen because ALTER TABLE checks for an existing NO= T >> NULL constraint before dropping the old column. So, finding the NOT NULL >> constraint on that old column causes it to skip adding one for the new >> column, even though the old constraint will be removed with the old colu= mn. > The same early check also breaks commands that do not drop the column at > all, only its not-null constraint, and v1 fixes those too. On 18.6 each > of these fails with "primary key column "a" is not marked NOT NULL": > > CREATE TABLE t (a int NOT NULL); > ALTER TABLE t ALTER COLUMN a DROP NOT NULL, ADD PRIMARY KEY (a); > > CREATE TABLE t (a int CONSTRAINT a_nn NOT NULL); > ALTER TABLE t DROP CONSTRAINT a_nn, ADD PRIMARY KEY (a); > > CREATE TABLE p (a int NOT NULL) PARTITION BY RANGE (a); > CREATE TABLE p1 PARTITION OF p FOR VALUES FROM (0) TO (10); > ALTER TABLE p ALTER COLUMN a DROP NOT NULL, ADD PRIMARY KEY (a); > > The two DROP NOT NULL forms work on 17.11; the DROP CONSTRAINT form has > no equivalent there. > > To see what else v1 changes, I ran 24 ALTER TABLE ... ADD PRIMARY KEY > scenarios on REL_18_STABLE at 459ef520d8f and master at c9c660e6ae0, > with and without v1, and compared the errors and the resulting catalog > state: the pg_constraint rows (with conislocal, coninhcount, > convalidated and connoinherit) and attnotnull. scenarios.sql is > attached. > > v1 changes exactly nine of them, all failures that go away: > > * dropping and re-adding the column: the reported case, a two-column > key with one column replaced, a partitioned table, an inheritance > parent, and the PRIMARY KEY subcommand written before the DROP > COLUMN; > * the three commands above; > * the reported case with a row in the table, which now fails with > "column "id" of relation "t" contains null values", as on 17. > > The other fifteen give identical errors and identical catalog state with > and without v1. Among them are plain ADD PRIMARY KEY on a partitioned > table and on an inheritance parent, ONLY on a parent whose child has or > lacks the not-null, an existing NOT VALID or NO INHERIT not-null, USING > INDEX, SET NOT NULL in the same command, an identity column, and ALTER > COLUMN TYPE in the same command. The results are the same on both > branches. > > Building a379061a22a and its parent: before it, all nine behave as they > do with v1; after it, all nine fail with "is not marked NOT NULL". So > the commit named in the patch is the one. > > v1's test covers the DROP COLUMN form only. The attached top-up adds > the three commands above to the same place in alter_table.sql. With v1 > make check passes on master and REL_18_STABLE; with the tests but > without the tablecmds.c change, alter_table fails on all four. > > Regards, > Manu --=20 //Ludvig Janiuk