RE: ADD/DROP CONSTRAINT and inheritance

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > On Wed, 23 May 2001, Christopher Kings-Lynne wrote:
> >> For the add/drop constraint clauses would it be an idea to
> change the syntax
> >> to:
> >>
> >> ALTER TABLE [ ONLY ] x ADD CONSTRAINT x;
> >> ALTER TABLE [ ONLY ] x DROP CONSTRAINT x;
>
> If the patch is coded in the same style as the existing ALTER code then
> this will happen automatically. Are you looking at current development
> tip as the comparison point for your changes?

I'm not sure what you mean here, Tom - I meant that the ONLY keyword could
be optional. I know that most of the existing ADD CONSTRAINT code does not
propagate constraints to children. However, if it was ever changed so that
it did - would it be nice to allow the DBA to specify that it should not be
propagated.

> > A related question is whether or not you can drop a constraint on a
> > subtable that's inherited from a parent.
>
> There is the question of whether it's a good idea to allow a constraint
> to exist on a parent but not on its subtables.

It seems to me that someone needs to sit down and decide on the inheritance
semantics that should be enforced (ideally) and then they can be coded to
the design.

> Seems like a bad idea to
> me. But as long as the default is to propagate these changes, I'm not
> really eager to prohibit DBAs from doing the other. Who's to say what's
> a misuse of inheritance and what's not...

At the moment we have:

* ADD CONSTRAINT does not propagate
* If you create a table with a CHECK constraint, then create a table that
inherits from that, the CHECK constraint _does_ propagate.

Seems to me that these behaviours are inconsistent...

Chris