> Agreed. I just tried out the scenarios laid out by you both with and without > the committed patch and AFAICS, normal inheritance semantics have been > preserved properly even after the commit.
No, they haven't. I didn't expect this to break anything when you have two constraints with different names. The problem is when you have two constraints with the same name.
Testing reveals that this is, in fact, broken:
rhaas=# create table A(ff1 int); CREATE TABLE rhaas=# create table B () inherits (A); CREATE TABLE rhaas=# create table C () inherits (B); CREATE TABLE rhaas=# alter table only b add constraint chk check (ff1 > 0); ALTER TABLE rhaas=# alter table a add constraint chk check (ff1 > 0); NOTICE: merging constraint "chk" with inherited definition ALTER TABLE
At this point, you'll find that a has a constraint, and b has a constraint, but *c does not have a constraint*. That's bad, because a's constraint wasn't "only" and should therefore have propagated all the way down the tree.
Apologies, I did not check this particular scenario.
I guess, here, we should not allow merging of the inherited constraint into an "only" constraint. Because that breaks the semantics for "only" constraints. If this sounds ok, I can whip up a patch for the same.
