Re: Updating system catalogs after a tuple deletion - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: Updating system catalogs after a tuple deletion
Date
Msg-id Pine.BSF.4.21.0105142148490.20223-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: Updating system catalogs after a tuple deletion  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 14 May 2001, 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.
> 
> 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).

I'm not sure it would.  You could have two constraint_ids with the same
name still as long as there's no constraint on constraint_name, both would
presumably be deleted on a drop.  Since rel_id is only part of
pg_relation_constraints you wouldn't want the constraint_name to be forced
unique (barring the spec definition) anyway, so there'd be nothing to
prevent you from naming all your constraints FRED, just you'd have a
better way to refer to a particular constraint than its name internally.



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: bug in pgcrypto 0.3
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] Postgres bug (working with iserverd)