Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-docs-owner+M8792=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
	id 1bYD2Q-0003VG-5C
	for pgsql-docs@arkaria.postgresql.org; Fri, 12 Aug 2016 14:02:18 +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+M8792=pgsql+2Ddocs=arkaria.postgresql.org@postgresql.org>)
	id 1bYD2P-0002p0-Jl
	for pgsql-docs@arkaria.postgresql.org; Fri, 12 Aug 2016 14:02:17 +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 1bYD23-00023P-Sy
	for pgsql-docs@postgresql.org; Fri, 12 Aug 2016 14:01:55 +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 1bYD21-0004Va-7C
	for pgsql-docs@postgresql.org; Fri, 12 Aug 2016 14:01:55 +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 u7CE1io0025577;
	Fri, 12 Aug 2016 10:01:44 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: 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: 
 <CAKFQuwZNS9YHs4xxgY3TEfHYP9fZjgsmuDn0+dLvD29k76=-sA@mail.gmail.com>
References: <20160805104837.1412.84915@wrigleys.postgresql.org>
 <fbb1360b-e450-aaf6-19bd-9bfcffb35ed7@2ndquadrant.com>
 <7aeb5291-b9ca-3a3c-0bd8-e60b56ec2693@2ndquadrant.fr>
 <CAKFQuwZNS9YHs4xxgY3TEfHYP9fZjgsmuDn0+dLvD29k76=-sA@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Fri, 12 Aug 2016 09:16:22 -0400"
Date: Fri, 12 Aug 2016 10:01:44 -0400
Message-ID: <25576.1471010504@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

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Aug 12, 2016 at 8:54 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>> I think the OP is complaining that cascading to b.v is not sufficiently
>> documented.  It seems logical to me that this would be the correct
>> behavior, but since at least one person got confused enough about it to
>> come and tell us, we should probably add some kind of warning or something.

> ​Yeah, it should probably be modified to something like:

> Automatically drop objects (tables, functions, etc...) that are contained
> in the schema.  Each object dropped is also done with the CASCADE option.
> This means that others schemas will be affected if they depend on objects
> in the named schema.

If we're going to add a warning about CASCADE being recursive, it would
logically need to be added to every last DROP command that has a CASCADE
option, which is most of them.  I don't necessarily object to that, but
we'd need a more boiler-plate, copy-and-pasteable phrasing.

A quick survey says that DROP SCHEMA is just about the only such command
that isn't documented with wording along the lines of "Automatically drop
objects that depend on the <whatever>", often with a parenthetical "such
as" to illustrate what sorts of objects might be dependent.  I think the
variant wording for DROP SCHEMA was intentional, with the thought that it
was easy to specify exactly which objects "depend on" a schema --- but is
that decision contributing to the confusion?

I'm inclined to suggest that maybe the generic phrasing could be
"Automatically drop objects that depend on the <whatever> [(such as ...)],
and in turn all objects that depend on those objects".

			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