On 2023-Aug-05, Dean Rasheed wrote:
> Hmm, thinking about this some more, I think this might be the wrong
> approach to fixing the original problem. I think it was probably OK
> that the NOT NULL constraint on the child was marked as inherited, but
> I think what should have happened is that dropping the PRIMARY KEY
> constraint on the parent should have caused the NOT NULL constraint on
> the child to have been deleted (in the same way as it would have been,
> if it had been a NOT NULL constraint on the parent).
Yeah, something like that. However, if the child had a NOT NULL
constraint of its own, then it should not be deleted when the
PK-on-parent is, but merely marked as no longer inherited. (This is
also what happens with a straight NOT NULL constraint.) I think what
this means is that at some point during the deletion of the PK we must
remove the dependency link rather than letting it be followed. I'm not
yet sure how to do this.
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.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Nunca se desea ardientemente lo que solo se desea por razón" (F. Alexandre)