Re: VIEW problem - Mailing list pgsql-general

From Stephan Szabo
Subject Re: VIEW problem
Date
Msg-id Pine.LNX.4.21.0010051050001.1130-100000@fnord.io.com
Whole thread Raw
In response to VIEW problem  (Tim Uckun <tim@diligence.com>)
List pgsql-general
>This sequence of events seems to break something.
>
>1) Create table foo
>2) create table bar
>3) create view foobar linking the two tables.
>4) drop table foo
>5) Create table foo (identical to first table)
>6) SELECT from view foobar.
>
>step six causes a relation not found error.
>
>Is this a bug? As long as the SQL statement that the view is based on is
>still valid why does it care if the table is dropped and recreated?

Sort of, but not the one you're thinking of.
Technically step 4 probably should have either prevented you from dropping
the table or automatically dropped the view based on whether you give
CASCADE or RESTRICT, however we don't currently support that notion
(hopefully 7.2 or so).

-----
SQL92 draft (11.18 <drop table statement>
     4) If RESTRICT is specified, then T shall not be referenced in
        the <query expression> of any view descriptor or the <search
        condition> of any constraint descriptor.

        Note: If CASCADE is specified, then such referencing objects
        will be dropped by the execution of the <revoke statement> spec-
        ified in the General Rules of this Subclause.


pgsql-general by date:

Previous
From: "Roderick A. Anderson"
Date:
Subject: Fake table name?
Next
From: "Nikolay Mijaylov"
Date:
Subject: RE: FW: URGENT: pgsql on the web server - memory problems....