RE: Updating system catalogs after a tuple deletion

On Wed, 23 May 2001, Christopher Kings-Lynne wrote:

> > 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 <table>_$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.
>
> Even if we implemented this, it wouldn't fix the problem of duplicated user
> specified constraint names under multiple inheritance. It seems a many-many
> pg_constraint table it the only clean solution...

I'm not sure that there is a workable solution for user specified names
without going the constraint names should be unique throughout solution
(which Tom doesn't want, and actually neither do I really even though I
bring it up as a compliance issue). I think that users will have to be
assumed to be smart enough not to screw themselves up with badly named
constraints.

We definately need better storage of our constraints. I liked the
constraint is stored once with pointers from referencing tables
idea.