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 по дате отправления: