Re: Fetch zero result rows when executing a query?

Sorry to revive this thread, I just had one additional thought...

To those advocating the deprecation of the max_rows parameter of Execute,
there's another argument to consider. max_rows isn't just there in order to
fetch, say, a single row of the result set and discard the rest (which is
what I originally asked about). There's also the function of retrieving the
resultset in chunks: getting 5 rows, then 10, etc. etc. Deprecating
max_rows would leave the user/driver only with the option of retrieving the
entire resultset in one go (for example, no option for the interleaving of
rows from several resultsets). And the lack of the ability to execute and
retrieve 0 rows hurts this scenario as well.

Just wanted to put it out there as another argument against deprecation.

On Wed, Feb 11, 2015 at 2:05 AM, Shay Rojansky <roji(at)roji(dot)org> wrote:

> Thanks for understanding Robert, that's more or less what I had in mind, I
> was mainly wondering if I were missing some deeper explanation for the
> absence of the possibility of requesting 0 rows.
>
> Regardless of all of the above, it's really no big deal. I'll go ahead and
> use max_rows=1 for now, hopefully you guys don't decide to deprecate it.
>
> Shay
>
> On Tue, Feb 10, 2015 at 3:00 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
>
>> On Sun, Feb 8, 2015 at 3:56 AM, Shay Rojansky <roji(at)roji(dot)org> wrote:
>> > Just to be precise: what is strange to me is that the max_rows feature
>> > exists
>> > but has no 0 value. You and Marko are arguing that the whole feature
>> should
>> > be
>> > deprecated (i.e. always return all rows).
>>
>> I think the fact that it has no zero value is probably just a
>> historical accident; most likely, whoever designed it originally
>> (probably twenty years ago) didn't think about queries with
>> side-effects and therefore didn't consider that wanting 0 rows would
>> ever be sensible. Meanwhile, a sentinel value was needed to request
>> all rows, so they used 0. If they'd thought of it, they might have
>> picked -1 and we'd not be having this discussion.
>>
>> FWIW, I'm in complete agreement that it would be good if we had this
>> feature. I believe this is not the first report we've had of
>> PostgreSQL doing things in ways that mesh nicely with standardized
>> driver interfaces. Whether we think those interfaces are
>> well-designed or not, they are standardized. When people use $OTHERDB
>> and have a really great driver, and then they move to PostgreSQL and
>> get one with more warts, it does not encourage them to stick with
>> PostgreSQL.
>>
>> .NET is not some fringe user community that we can dismiss as
>> irrelevant. We need users of all languages to want to use PostgreSQL,
>> not just users of languages any one of us happens to personally like.
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>