Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch
> I'd say that normally you're not using cursors because you intend to throw
> away 80% or 90% of the result set, but instead you'r
At 10:51 31/10/00 +0100, Peter Eisentraut wrote:
>Tom Lane writes:
>
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch
>
>I'd say that normally you're not using cursors because you intend to throw
>away 80% or 90% of the result set, but instead y
Tom Lane writes:
> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
> basis of 10%-or-so fetch
I'd say that normally you're not using cursors because you intend to throw
away 80% or 90% of the result set, but instead you're using it because
it's convenient in your programmi
At 12:18 PM 10/27/00 -0400, Tom Lane wrote:
>Hiroshi was a little concerned about this change in behavior, and
>so the first order of business is whether anyone wants to defend the
>old way? IMHO it was incontrovertibly a bug, but ...
Sure feels like a bug to me. Having it ignored isn't what I
At 12:18 27/10/00 -0400, Tom Lane wrote:
>
>1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
>just as reasonable, if people want to argue about the exact number;
>perhaps a SET variable is in order?). 10%
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:18 27/10/00 -0400, Tom Lane wrote:
>> 1. If DECLARE CURSOR does not contain a LIMIT, continue to plan on the
>> basis of 10%-or-so fetch (I'd consider anywhere from 5% to 25% to be
>> just as reasonable, if people want to argue about the exact numb
