Re: not null constraints, again

On 2024-Oct-10, jian he wrote:

> tricky case:
> drop table if exists part, part0 cascade;
> create table part (a int not null) partition by range (a);
> create table part0 (a int primary key);
> alter table part attach partition part0 for values from (0) to (1000);
> alter table ONLY part add primary key(a);
> alter table ONLY part drop constraint part_a_not_null;
> -- alter table ONLY part alter column a drop not null;
>
>
> Now we are in a state where a partitioned
> table have a primary key but doesn't have a not-null constraint for it.

Oh, of course! This means that the comment in RelationGetIndexList
(reverted in 6f8bb7c1e961) was incorrect: it was not only about
pg_dump's strategy for dumping PKs in partitioned tables, but it was
also about protecting those not-nulls under PKs for the same tables. By
removing it (which I did when I forward-ported the reversal of the
reversal) I removed that protection, and failed to notice because we
don't have this test case.

Anyway, I put it back, fixing the comment; and I also had to change
RelationGetPrimaryKeyIndex API to have an additional "bool deferrable_ok"
parameter, so that it knows it can return a deferrable PK. This is
needed by the code just added in dropconstraint_internal().

I also added your test case.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Officer Krupke, what are we to do?
Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke")