Re: Updating system catalogs after a tuple deletion

Philip Warner <pjw@rhyme.com.au> writes:
> It is worth considering skipping the entire 'copy to children' approach?
> Something like:
> pg_constraints(constraint_id, constraint_name, constraint_details....)
> pg_relation_constraints(rel_id, constraint_id)
> Then, when we drop constraint 'FRED', the relevant rows of these tables are
> deleted. There is only ever one copy of the constraint definition.

This would work if we abandon the idea that a table cannot have
multiple constraints of the same name (which seems like an unnecessary
restriction to me anyway).

A small advantage of doing it this way is that it'd be easier to detect
the case where the same constraint is multiply inherited from more than
one parent, as in
table P has a constraint
C1 inherits from P
C2 inherits from P
GC1 inherits from C1,C2

Currently, GC1 ends up with two duplicate constraints, which wastes time
on every insert/update.  Not a very big deal, perhaps, but annoying.
It'd be nice to recognize and remove the extra constraint.  (However,
the inherited-from link that I proposed a few minutes ago could do that
too, if the link always points at the original constraint and not at the
immediate ancestor.)

BTW, any proposed DROP CONSTRAINT algorithm should be examined to make
sure it doesn't fail on this sort of structure ...
        regards, tom lane