Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-docs-owner+M8803=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
	id 1bYKWo-0005d1-LD
	for pgsql-docs@arkaria.postgresql.org; Fri, 12 Aug 2016 22:02:10 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84_2)
	(envelope-from
 <pgsql-docs-owner+M8803=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
	id 1bYKWn-00041A-KQ
	for pgsql-docs@arkaria.postgresql.org; Fri, 12 Aug 2016 22:02:09 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1bYKWR-0003YX-Le
	for pgsql-docs@postgresql.org; Fri, 12 Aug 2016 22:01:47 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1bYKWO-0005dL-Pz
	for pgsql-docs@postgresql.org; Fri, 12 Aug 2016 22:01:47 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id u7CM1bKU024532;
	Fri, 12 Aug 2016 18:01:37 -0400
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: <20160812213205.GA717717@alvherre.pgsql>
References: <20160812213205.GA717717@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Fri, 12 Aug 2016 17:32:05 -0400"
Date: Fri, 12 Aug 2016 18:01:37 -0400
Message-ID: <24531.1471039297@sss.pgh.pa.us>
X-Pg-Spam-Score: -2.4 (--)
List-Archive: <http://archives.postgresql.org/pgsql-docs>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-docs.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@postgresql.org>
List-Post: <mailto:pgsql-docs@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-docs>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-docs>
X-Mailing-List: pgsql-docs
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> There's plenty of discoverability already.  The documentation suggests
>> 
>> (If you want to check what <command>DROP ... CASCADE</> will do,
>> run <command>DROP</> without <literal>CASCADE</> and read the
>> <literal>DETAIL</> output.)

> True, but the DETAIL is capped at 100 objects (per
> reportDependentObjects);

True, though I've heard no complaints about that (and in the extreme,
you can look into the server log).

> also, object locks need to be acquired, which
> can be very troublesome if you discover that some frequently-used object
> is in the set to be dropped, by some unfortunate accident.

You'd need the object locks in any case, to be sure things hold still long
enough for their dependencies to be examined.  It's possible a weaker lock
type would suffice, but I'm not sure; we generally don't require exclusive
lock on an object to add or remove dependencies on it.

I'm not necessarily against adding a function to report the dependencies
as a table rather than NOTICE output.  But things have been like this
for quite a few years and I can count the number of requests for such a
function without running out of thumbs.  Doesn't seem very high priority.

			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