Re: Updating system catalogs after a tuple deletion

At 23:34 14/05/01 -0400, Tom Lane wrote:
>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.
...
>
>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
>

Other advantages include:
- easy ALTER TABLE ALTER CONSTRAINT (does it exist?)- cleaner pg_dump code- possibility to have NULL names for system
objectswhich avoids any
 
namespace corruption.

It's probably worth adding extra information to the pg_constraints table to
include inform,ation about how it was created (pk, fk, user-defined etc).


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/