Re: [GENERAL] Retrieving query results - Mailing list pgsql-general

From Igor Korot
Subject Re: [GENERAL] Retrieving query results
Date
Msg-id CA+FnnTxaA2cuEQiMx4-XFwBX3mdFL5wRq_xcN_+chNM-HdQtYg@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Retrieving query results  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] Retrieving query results  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi, guys,


On Thu, Aug 24, 2017 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot <ikorot01@gmail.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.

Does this mean that querying a table with a big number of rows will
crash the psql?

Thank you.

>
>                         regards, tom lane


pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Retrieving query results
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Retrieving query results