Alvaro Herrera writes:
> Tom Lane wrote:
>> 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
Alvaro Herrera 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 b
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.
Tom Lane wrote:
> > 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
On Fri, Aug 12, 2016 at 6:01 PM, Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> There's plenty of discoverability already. The documentation suggests
> >>
> >> (If you want to check what DROP ... CASCADE will do,
> >> run DROP without CASCADE and read the
> >> DETAIL output.)
Alvaro Herrera writes:
> Tom Lane wrote:
>> There's plenty of discoverability already. The documentation suggests
>>
>> (If you want to check what DROP ... CASCADE will do,
>> run DROP without CASCADE and read the
>> DETAIL output.)
> True, but the DETAIL is capped at 100 objects (per
> reportD
Tom Lane wrote:
> Alvaro Herrera 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 DROP ... CASCADE wi
Alvaro Herrera 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 DROP ... CASCADE will do,
run DROP without CAS
Tom Lane wrote:
> I'm inclined to suggest that maybe the generic phrasing could be
> "Automatically drop objects that depend on the [(such as ...)],
> and in turn all objects that depend on those objects".
I think it'd be a good idea to add some more discoverability: what would
be deleted if an
I wrote:
> 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.
> ...
"David G. Johnston" writes:
> On Fri, Aug 12, 2016 at 8:54 AM, Vik Fearing 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 i
On Fri, Aug 12, 2016 at 8:54 AM, Vik Fearing wrote:
> On 12/08/16 14:47, Peter Eisentraut wrote:
> > On 8/5/16 6:48 AM, denisa.cirste...@asentinel.com wrote:
> >> Page: https://www.postgresql.org/docs/9.5/static/sql-dropschema.html
> >> Description:
> >>
> >> DROP SCHEMA ... CASCADE has a behavio
On 12/08/16 14:47, Peter Eisentraut wrote:
> On 8/5/16 6:48 AM, denisa.cirste...@asentinel.com wrote:
>> Page: https://www.postgresql.org/docs/9.5/static/sql-dropschema.html
>> Description:
>>
>> DROP SCHEMA ... CASCADE has a behavior that has not been documented.
>> According to the documentation:
On 8/5/16 6:48 AM, denisa.cirste...@asentinel.com wrote:
> Page: https://www.postgresql.org/docs/9.5/static/sql-dropschema.html
> Description:
>
> DROP SCHEMA ... CASCADE has a behavior that has not been documented.
> According to the documentation: "CASCADE - Automatically drop objects
> (tables,
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.5/static/sql-dropschema.html
Description:
DROP SCHEMA ... CASCADE has a behavior that has not been documented.
According to the documentation: "CASCADE - Automatically drop objects
(tables,
15 matches
Mail list logo
