Re: pg_depend
От | Bill Studenmund |
---|---|
Тема | Re: pg_depend |
Дата | |
Msg-id | Pine.NEB.4.21.0107181014550.504-100000@candlekeep.home-net.internetconnect.net обсуждение исходный текст |
Ответ на | Re: pg_depend (Hiroshi Inoue <Inoue@tpf.co.jp>) |
Список | pgsql-hackers |
On Wed, 18 Jul 2001, Hiroshi Inoue wrote: > Oops I made a mistake. > Reference name is needed not an object name, > i.e > object relid > object oid > relerence relid > reference oid > reference name > > create table a (...); > create view view_a as select .. from a; > > Then we have an pg_depend entry e.g. > > pg_class_relid > oid of the view_a > pg_class_relid > oid of the table a > 'a' the name of the table > > and so on. > > drop table a; (unadorned drop). > > Then the above entry would be changed to > > pg_class_relid(unchanged) > oid of the view_s(unchagned) > pg_class_relid(unchanged) > InvalidOid > 'a' the name of the table(unchanged) > > create table a (...); > > Then the pg_depend entry would be > > pg_class_relid(unchanged) > oid of the view_s(unchagned) > pg_class_relid(unchanged) > the oid of the new table a > 'a' the name of the table(unchanged) This step I disagree with. Well, I disagree with the automated aspect of the update. How does postgres know that the new table a is sufficiently like the old table that it should be used? A way the DBA could say, "yeah, restablish that," would be fine. Which is better, a view which is broken as the table it was based off of was dropped (even though there's a table of the same name now) or a view which is broken because there is now a table whose name matches its old table's name, but has different columns (either names or types)? I'd say #1. Take care, Bill
В списке pgsql-hackers по дате отправления: