> 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.
Regards,
Nikhils