Re: pg_views.definition

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_views.definition
Date: 2002-07-16 16:05:25
Message-ID: 13066.1026835525@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jan Wieck <JanWieck(at)Yahoo(dot)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 objects too

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Lockhart 2002-07-16 16:07:10 Re: [SQL] line datatype
Previous Message Tim Hart 2002-07-16 16:00:34 Re: [SQL] line datatype