From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Updating system catalogs after a tuple deletion |
Date: | 2001-05-15 02:56:16 |
Message-ID: | ECEHIKNFIMMECLEBJFIGIEIOCAAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Lastly, inheritance? I plan to leave out worrying about inheritance for
> > starters, especially since it seems that half the constraints when added
> > don't even propagate themselves properly to child tables...
>
> 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?
I recently had a patch of mine committed to heap.c (rev 1.163->1.164) in the
AddRelationRawConstraints function that loops to make sure that
automatically generated constraint names are unique. It seems to me that it
would be relatively straightforward to make sure that the constraint name is
unique in all the inherited tables as well.
I've never messed with inheritance, so I probably won't look at implementing
that any time soon...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-15 03:10:44 | Re: Updating system catalogs after a tuple deletion |
Previous Message | Bruce Momjian | 2001-05-15 02:51:13 | Re: pg_index.isclustered can work |