The following bug has been logged online:

Bug reference: 1524
Logged by: Dennis van Dok
Email address: d.vandok (AT) ecn (DOT) nl
PostgreSQL version: 7.3.4
Operating system: Linux
Description: drop view cascade deletes other user's views
Details:

Using DROP VIEW or DROP TABLE with CASCADE will drop all dependent views,
even those that aren't owned by the caller.

steps to recreate behaviour:

log in as user1
=> create table t1 (col1 integer);
CREATE TABLE

log out. Log in as user2.
=> create view v1 as select * from t1;
CREATE VIEW

Note that at this point, user1 can not drop v1, nor select from it, while
user2 cannot select from either t1 or v1.

Log out, and log in again as user1
=> drop table t1 cascade;
NOTICE: Drop cascades to rule _RETURN on view v1
NOTICE: Drop cascades to view v1
DROP TABLE

Poof.

Now, I realize that user1 SHOULD be able to drop his own table, no matter
what. But it seems awfully unpolite to pull the view from under user2's nose
like that, even if it has become disfunctional after dropping t1.

We happen to be in a situation where one user is managing a 'master view'
for a data aquisition system, listing all signals as fields. Other users
derive their own (elaborate) views from it. Whenever the master view is
updated, all their hard work is send into limbo.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

"Dennis van Dok" <d.vandok (AT) ecn (DOT) nl> writes:
This is per SQL spec.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend