On Wed, 20 Feb 2002, Philip Warner wrote:
> At 14:05 19/02/02 -0800, Stephan Szabo wrote:
> >
> >Check constraints and not null I believe are inherited by default.
> >But I just thought of a case that won't dump and restore the same as it
> >was originally made because we support ONLY on alter table add constraint.
> >
> >create table z(a int);
> >create table z2() inherits(z);
> >alter table only z add constraint foo1 check(a>4);
> >
> >will make z have a constraint on a but not z2 and the check will get
> >dumped as part of z's definition which will restore with z2 having
> >the check.
>
> This brings to mind a couple of questions:
>
> 1. Do you have plans to support inhertiance of PK constraints?
If you mean me personally, not in the short term. I don't think
that pk over an inheritance tree means a copy of the constraint
for each table either, so it's not quite the same as some of the
other constraints.
> 2. Does/will DROP CONSTRAINT support ONLY?
Pretty sure it does. I also think it'll let you drop an inherited
constraint from a child table which can get you into the same state as
the create/alter above. Does dropping inherited constraints from
children or allowing constraints to be added to only the parent table
make sense? I only wonder because unless you're using only on the queries
you'll see the rows in the children that violate the constraint which
seems kinda odd to me.
