Date: Fri, 12 Aug 2016 17:32:05 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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
Message-ID: <20160812213205.GA717717@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20493.1471035687@sss.pgh.pa.us>
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > I think it'd be a good idea to add some more discoverability: what would
> > be deleted if an object X were to be deleted?
> 
> 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.)
>
> Or you could do BEGIN; DROP ... CASCADE; ROLLBACK.

True, but the DETAIL is capped at 100 objects (per
reportDependentObjects); 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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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