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.
> ...
Simon Riggs writes:
> On 12 August 2016 at 16:23, Tom Lane wrote:
>> I think "global" might have implications we don't want. How about
>> adding ", based on a system-generated seed"?
> What I was trying to express was that
> SELECT setseed(dp);
> SELECT * FROM foo TABLESAMPLE ...;
> SELECT * F
On 12 August 2016 at 18:54, Tom Lane wrote:
> Simon Riggs writes:
>> On 12 August 2016 at 16:23, Tom Lane wrote:
>>> I think "global" might have implications we don't want. How about
>>> adding ", based on a system-generated seed"?
>
>> What I was trying to express was that
>
>> SELECT setseed(
On 12 August 2016 at 16:23, Tom Lane wrote:
> Simon Riggs writes:
>> But now you mention it, I agree with you. Let's put it back to say
>> "sample" but also explain where that new sample comes from... my
>> attempt to explain this better is in square brackets
>
>> "If REPEATABLE is not given then
Simon Riggs writes:
> But now you mention it, I agree with you. Let's put it back to say
> "sample" but also explain where that new sample comes from... my
> attempt to explain this better is in square brackets
> "If REPEATABLE is not given then a new random sample will be taken for
> each query
On 12 August 2016 at 15:24, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 August 2016 at 17:21, wrote:
>>> > If REPEATABLE is not given then a new random sample is selected for
>>> each
>>> query.
>>>
>>> the word "sample" should be "seed". Of course it
>>> results in a new random
>>> sample
Simon Riggs writes:
> On 11 August 2016 at 17:21, wrote:
>> > If REPEATABLE is not given then a new random sample is selected for each
>> query.
>>
>> the word "sample" should be "seed". Of course it results
>> in a new random
>> sample as well, but IMHO this sentence is about what happens to
"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,
On 11 August 2016 at 17:21, wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/sql-select.html
> Description:
>
> Regarding the TABLESAMPLE documentation on [1], I think in the following
> sentence
>
> > If REPEATABLE
21 matches
Mail list logo
