Re: cataloguing NOT NULL constraints

On 05.08.23 21:50, Dean Rasheed wrote:
>> Anyway, I was at the same time fixing the other problem you reported
>> with inheritance (namely, adding a PK ends up with the child column
>> being marked NOT NULL but no corresponding constraint).
>>
>> At some point I wondered if the easy way out wouldn't be to give up on
>> the idea that creating a PK causes the child columns to be marked
>> not-nullable.  However, IIRC I decided against that because it breaks
>> restoring of old dumps, so it wouldn't be acceptable.
>>
>> To make matters worse: pg_dump creates the PK as
>>
>>    ALTER TABLE ONLY parent ADD PRIMARY KEY ( ... )
>>
>> note the ONLY there.  It seems I'm forced to cause the PK to affect
>> children even though ONLY is given.  This is undesirable but I don't see
>> a way out of that.
>>
>> It is all a bit of a rat's nest.
>>
> 
> I wonder if that could be made to work in the same way as inherited
> CHECK constraints -- dump the child's inherited NOT NULL constraints,
> and then manually update conislocal in pg_constraint.

I wonder whether the root of these problems is that we mix together 
primary key constraints and not-null constraints.  I understand that 
right now, with the proposed patch, when a table inherits from a parent 
table with a primary key constraint, we generate not-null constraints on 
the child, in order to enforce the not-nullness.  What if we did 
something like this instead: In the child table, we don't generate a 
not-null constraint, but instead a primary key constraint entry.  But we 
mark the primary key constraint somehow to say, this is just for the 
purpose of inheritance, don't enforce uniqueness, but enforce 
not-nullness.  Would that work?