> postgres=# CREATE TABLE t1(c0 int, c1 int); > postgres=# ALTER TABLE t1 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > postgres=# ALTER TABLE t1 DROP c1; > > postgres=# ALTER TABLE t1 ALTER c0 DROP NOT NULL; > ERROR: could not find not-null constraint on column "c0", relation "t1"
Ooh, hah, what happens here is that we drop the PK constraint indirectly, so we only go via doDeletion rather than the tablecmds.c code, so we don't check the attnotnull flags that the PK was protecting.
> The attached patch is my workaround solution. Look forward your apply.
Yeah, this is not a very good approach -- I think you're just guessing that the column is marked NOT NULL because a PK was dropped in the past -- but really what this catalog state is, is corrupted contents because the PK drop was mishandled. At least in theory there are other ways to drop a constraint other than dropping one of its columns (for example, maybe this could happen if you drop a collation that the PK depends on). The right approach is to ensure that the PK drop always does the dance that ATExecDropConstraint does. A good fix probably just moves some code from dropconstraint_internal to RemoveConstraintById.
RemoveConstraintById() should think recurse(e.g. partition table)? I'm not sure now.
If we should think process recurse in RemoveConstraintById(), the function will look complicated than before.
