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?