Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA64339 for ; Sun, 2 May 1999 12:13:04 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA13410; Sun, 2 May 1999 12:11:56 -0400 (EDT) To: Henk Jan Barendregt cc: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] [libpq] Return value of int In-reply-to: Your message of Sun, 02 May 1999 09:32:52 +0000 <372C1BC4.A71000FD@barendregt.xs4all.nl> Date: Sun, 02 May 1999 12:11:56 -0400 Message-ID: <13408.925661516@sss.pgh.pa.us> From: Tom Lane Henk Jan Barendregt writes: > How can i use libpq to return an int value when i access an INT or INT4 > value Use atoi() ... what comes out of libpq is a character string always. It's up to you to convert it to whatever form you want it in. Actually, if you are really intent on avoiding the conversion step you can use a binary cursor and get the data in whatever the backend's internal format is. However I can't recommend this. I've found by measurement that the conversion time is insignificant compared to the rest of the work involved in a query, even for expensive-to-convert datatypes like DATETIME. And for that trivial savings you expend a lot of programming effort: you have to know what the backend's internal format *is*, and you have to be prepared to deal with cross-machine compatibility issues (maybe the backend is running on a machine with different endianness than your app is ... how will you even know?), cross-Postgres-version changes in the internal representation, yadda yadda. Much better to take the character string. But if you insist on doing it the hard way, read about DECLARE CURSOR and FETCH in the manual. regards, tom lane