From: Manu <manuelreyesbravo@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Ludvig Janiuk <ludvig.janiuk@proton.me>, pgsql-bugs@lists.postgresql.org
Subject: Re: 42P16 error when dropping and adding column
Date: Mon, 28 Sep 2026 14:55:21 -0300
Message-ID: <179061812106.376834.11309923193808938178@gmail.com>
In-Reply-To: 
 <CAHGQGwGPJNq_p8w5W9jvA__6GOmFk5A0K7Vxw3ab0ASotvQy3g@mail.gmail.com>
References: 
 <CAHGQGwGPJNq_p8w5W9jvA__6GOmFk5A0K7Vxw3ab0ASotvQy3g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/179061812106.376834.11309923193808938178%40gmail.com>
Precedence: bulk

Hi Fujii-san,

> Thanks! Attached is v2 patch, which includes your tests.
> While working with the v1 patch, I found that the following DDL failed
> [...] v2 fixes this regression introduced by v1.

I ran v2 through a differential of 32 ALTER TABLE cases on master
(a5447a2deac) and REL_18_STABLE, cassert builds, comparing each build
against unpatched master and REL_18: the 24 from the v1 review plus 8
around a separate named NOT NULL combined with ADD PRIMARY KEY.

v2 fixes the reported case and the seven other 42P16 forms in the set,
each with the expected catalog state (the primary key and an
auto-created NOT NULL).  The regression you caught,

    ALTER TABLE t ALTER COLUMN id DROP NOT NULL,
      ADD PRIMARY KEY (id), ADD CONSTRAINT hoge NOT NULL id;

fails on v1 with "cannot create not-null constraint" and succeeds on
v2, as do the drop-column and partitioned variants of it.

No case in the set errors on v2 while succeeding on unpatched master or
REL_18.  The scenarios where a primary key still cannot be added (ONLY
on an inheritance parent, a column that already holds a null row, a
redundant named NOT NULL on a column that already has one) error
identically on all three.  master and REL_18 give the same result on
every case, and make check passes on both.

Thanks for folding in the tests.

Regards,
Manu