The following bug has been logged online: Bug reference: 1524 Logged by: Dennis van Dok Email address: [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
