From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, denisa(dot)cirstescu(at)asentinel(dot)com, "pgsql-docs(at)postgresql(dot)org" <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: Undocumented behavior od DROP SCHEMA ... CASCADE |
Date: | 2016-08-12 22:48:51 |
Message-ID: | 29387.1471042131@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-08-12 22:58:32 | Re: Undocumented behavior od DROP SCHEMA ... CASCADE |
Previous Message | Alvaro Herrera | 2016-08-12 22:28:36 | Re: Undocumented behavior od DROP SCHEMA ... CASCADE |