RE: Updating system catalogs after a tuple deletion

(This machine still is having trouble with mx records :( )

On Mon, 21 May 2001, Christopher Kings-Lynne wrote:

> > 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?
> 
> It occurs to me that there's a solution to this problem.  All you need to do
> is in heap.c in the piece of code I modified earlier for generating
> constraint names and checking specified ones you simply make sure it is
> unique for the parent table and for ALL its children.
> 
> This will stop people (1) adding named constraints that aren't unique across
> all children, noting that these new constraints need to be added to the
> children as well as the parent and (2) dynamically generated constraint
> names will be unique across all children and also can then be immediately
> propagated to inherited tables.
> 
> With this enforced, surely there is a _guaranteed_ match between the name of
> a parent constraint and the same constraint in the inherited tables?  The
> only problem, I guess, would be when you import data from old versions of
> PostgreSQL into a new version that has this assumption/restriction.

Actually, I realized that in the face of multiple inheritance, dynamically
generated constraint names still fail with our current default naming
scheme.  What happens when two tables both have a $1 and then you inherit
from both of them, at this point it's pretty much too late to rename the
constraint on one of the parents and I think right now the constraints get
named $1 and $2.  Either, we should punt, and make it so they both end up
$1, or perhaps we should change $1 to something like _$1 where
table is the table name of the table on which the constraint was defined.
So if you have table1 with an unnamed constraint, it and all of its
children would see the constraint as table1_$1.