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)
