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?
