Re: Updating system catalogs after a tuple deletion
От | Stephan Szabo |
---|---|
Тема | Re: Updating system catalogs after a tuple deletion |
Дата | |
Msg-id | Pine.BSF.4.21.0105142148490.20223-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Updating system catalogs after a tuple deletion (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: