Re: Review: Non-inheritable check constraints

> > 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