From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Updating system catalogs after a tuple deletion |
Date: | 2001-05-15 03:10:44 |
Message-ID: | 28930.989896244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> Actually this brings up a problem I'm having with ALTER TABLE ADD
> CONSTRAINT and since it mostly affects you with DROP CONSTRAINT, I'll
> bring it up here. If you have a table that has check constraints or
> is inherited from multiple tables, what's the correct way to name an
> added constraint that's being inherited? If it's $2 in the parent,
> but the child already has a $2 defined, what should be done? The
> reason this affects drop constraint is knowing what to drop in the
> child. If you drop $2 on the parent, what constraint(s) on the child
> get dropped?
Seems like depending on the name is inadequate. Perhaps a column should
be added to pg_relcheck to show that a constraint has been inherited.
Maybe "rcinherit" = OID of parent's equivalent constraint, or 0 if
constraint was not inherited. Then you could do the right things
without making any assumptions about constraint names being the same.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2001-05-15 03:24:46 | RE: Updating system catalogs after a tuple deletion |
Previous Message | Christopher Kings-Lynne | 2001-05-15 02:56:16 | RE: Updating system catalogs after a tuple deletion |