RE: Updating system catalogs after a tuple deletion

> 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.

Chris