Re: Retrieving query results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Igor Korot <ikorot01(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Retrieving query results
Date: 2017-08-24 12:51:36
Message-ID: 32584.1503579096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01(at)gmail(dot)com> wrote:
>> [quote]
>> PQntuples
>>
>> Returns the number of rows (tuples) in the query result. Because it
>> returns an integer result, large result sets might overflow the return
>> value on 32-bit operating systems.
>>
>> int PQntuples(const PGresult *res);
>> [/quote]
>>
>> Is there another way to not to overflow the result?

> Not really with the existing API.

Actually, that documentation note is pretty beside-the-point, if not
outright wrong. The real issue here is that libpq's internal row counter
is also a plain int. As are the rownumber arguments to PQgetvalue and so
on. While we could widen that internal counter, it's useless to do so
as long as these API choices prevent applications from dealing with
resultsets of more than 2G rows.

I think what we need is to (1) introduce some error checking in libpq so
that it reports an error if the resultset exceeds 2G rows --- right now
it'll just crash, I fear, and (2) change the documentation so that this
is explained as a library-wide limitation and not just a problem with
PQntuples.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Korot 2017-08-24 13:47:42 Re: Retrieving query results
Previous Message Tom Lane 2017-08-24 12:18:17 Re: Explain analyse and toasted data.