Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dkreJ-00023N-5M for pgsql-general@arkaria.postgresql.org; Thu, 24 Aug 2017 12:54:15 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dkreI-00038D-OC for pgsql-general@arkaria.postgresql.org; Thu, 24 Aug 2017 12:54:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dkrbq-0005bl-UK for pgsql-general@postgresql.org; Thu, 24 Aug 2017 12:51:42 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dkrbn-00047l-VO for pgsql-general@postgresql.org; Thu, 24 Aug 2017 12:51:42 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v7OCpaM6032585; Thu, 24 Aug 2017 08:51:36 -0400 From: Tom Lane To: Michael Paquier cc: Igor Korot , pgsql-general Subject: Re: Retrieving query results In-reply-to: References: Comments: In-reply-to Michael Paquier message dated "Wed, 23 Aug 2017 09:32:54 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32583.1503579096.1@sss.pgh.pa.us> Date: Thu, 24 Aug 2017 08:51:36 -0400 Message-ID: <32584.1503579096@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org Michael Paquier writes: > On Wed, Aug 23, 2017 at 3:19 AM, Igor Korot 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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general