Re: pg_views.definition
От | Tom Lane |
---|---|
Тема | Re: pg_views.definition |
Дата | |
Msg-id | 13066.1026835525@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg_views.definition (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: pg_views.definition
|
Список | pgsql-hackers |
Jan Wieck <JanWieck@Yahoo.com> writes: >> We actually reverse it on the fly: > We do, but as soon as you break the view by dropping an underlying > object it fails to reconstruct. So having the original view definition > at hand could be useful for some ALTER VIEW RECOMPILE command. Note that the assumptions underlying this discussion have changed in CVS tip: you can't break a view by dropping underlying objects. regression=# create table foo(f1 int, f2 text); CREATE TABLE regression=# create view bar as select * from foo; CREATE VIEW regression=# drop table foo; NOTICE: rule _RETURN on view bar depends on table foo NOTICE: view bar depends on rule _RETURN on view bar ERROR: Cannot drop table foo because other objects depend on it Use DROP ... CASCADE to drop the dependent objectstoo or regression=# drop table foo cascade; NOTICE: Drop cascades to rule _RETURN on view bar NOTICE: Drop cascades to view bar DROP TABLE -- bar is now gone Auto reconstruction of a view based on its original textual definition is still potentially interesting, but I submit that it won't necessarily always give the right answer. regards, tom lane
В списке pgsql-hackers по дате отправления: