Skip site navigation (1) Skip section navigation (2)

RE: ADD/DROP CONSTRAINT and inheritance

From: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: ADD/DROP CONSTRAINT and inheritance
Date: 2001-05-24 02:40:36
Message-ID: ECEHIKNFIMMECLEBJFIGKEKBCAAA.chriskl@familyhealth.com.au (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-05-24 02:59:53
Subject: Re: ADD/DROP CONSTRAINT and inheritance
Previous:From: John ReidDate: 2001-05-24 02:35:47
Subject: uml diagrams of system catalogues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group