From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: "David G. Johnston" <david.g.johnston@gmail.com>,
        Vik Fearing <vik@2ndquadrant.fr>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        denisa.cirstescu@asentinel.com,
        "pgsql-docs@postgresql.org" <pgsql-docs@postgresql.org>
Subject: Re: Undocumented behavior od DROP SCHEMA ... CASCADE
In-reply-to: <20160812222836.GA722084@alvherre.pgsql>
References: <20160812222836.GA722084@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Fri, 12 Aug 2016 18:28:36 -0400"
Date: Fri, 12 Aug 2016 18:48:51 -0400
Message-ID: <29387.1471042131@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> David G. Johnston wrote:
>> If we are looking to improve things here I'd at least consider having the
>> default cascade to be safe and not drop persisted data (I suppose that
>> could functions linked to functional indexes...) and have a separate flag
>> that would also be permitted to destroy data.  Having such a dependency
>> listing query distinguish between data-loss and other would be a good
>> intermediate step.

> Well, if you happen to drop a view for which you no longer have the
> definition, you may be similarly screwed.  I prefer the approach that we
> consider all drops as potentially dangerous.

There's also the minor problem that the SQL standard is quite clear about
what DROP CASCADE means, and it ain't that.

			regards, tom lane


-- 
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs