Thread: [libpq] Return value of int
Hello, How can i use libpq to return an int value when i access an INT or INT4 value For example : result = PQexec (connection,"SELECT integervalue FROM integertable"); I have followed the example nr 3 in the pogrammers guide but i still get a char * when i use PQgetvalues Thanks in advance, Henk Jan Barendregt
Henk Jan Barendregt <henkjan@barendregt.xs4all.nl> 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
Tom Lane wrote: > > Henk Jan Barendregt <henkjan@barendregt.xs4all.nl> 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 Thanks a lot for the explanation. It is gave me some good reasons to stay on my path and convert the results to whatever i need. Henk Jan
Thus spake Tom Lane
> Henk Jan Barendregt <henkjan@barendregt.xs4all.nl> 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.
Regarding this, it would be nice if libpq had some official, documented
way of determining the type of the field. Currently I deal with this
in PyGreSQL by stealing some #defines from src/include/catalog/pg_type.h,
something that isn't normally available to application programmers. In
fact, maybe we just have to move those #defines into postgres.h or
something that is in the public include directory.
Just thinking out loud.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> Regarding this, it would be nice if libpq had some official, documented
> way of determining the type of the field. Currently I deal with this
> in PyGreSQL by stealing some #defines from src/include/catalog/pg_type.h,
> something that isn't normally available to application programmers.
Well, I don't see a big problem with stealing the defines --- the odds
of the OID for INT4, say, ever changing are pretty low.
But of course the "official, documented" way to find out what a given
type OID means is
SELECT typname FROM pg_type WHERE oid = <whatever>;
If you kept a cache of type info on the application side, you could
probably even make this fast enough to be a reasonable approach :-)
regards, tom lane
On Sun, 2 May 1999, Tom Lane wrote:
> "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> > Regarding this, it would be nice if libpq had some official, documented
> > way of determining the type of the field. Currently I deal with this
> > in PyGreSQL by stealing some #defines from src/include/catalog/pg_type.h,
> > something that isn't normally available to application programmers.
>
> Well, I don't see a big problem with stealing the defines --- the odds
> of the OID for INT4, say, ever changing are pretty low.
>
> But of course the "official, documented" way to find out what a given
> type OID means is
>
> SELECT typname FROM pg_type WHERE oid = <whatever>;
I'm just getting started on fiddling with libpq. I am wondering why
this passage from man libpq doesn't address this issue? I'm not being
a smarty here, I just don't know the answer.
PQftype returns the field type associated with the given field index. The integer returned is an
internal coding of the type. Field indices start at 0. Oid PQftype(PGresult *res,
int field_num);
Hugh Lawson
Greensboro, North Carolina
hglawson@nr.infi.net
Hugh Lawson <hglawson@nr.infi.net> writes:
> I'm just getting started on fiddling with libpq. I am wondering why
> this passage from man libpq doesn't address this issue? I'm not being
> a smarty here, I just don't know the answer.
> PQftype returns the field type associated with the
> given field index. The integer returned is an
> internal coding of the type.
Unless I missed what D'Arcy was getting at, his point was that when
PQftype tells you the field type is, say, 23, how do you know what
that means?
regards, tom lane
Thus spake Tom Lane
> Hugh Lawson <hglawson@nr.infi.net> writes:
> > I'm just getting started on fiddling with libpq. I am wondering why
> > this passage from man libpq doesn't address this issue? I'm not being
> > a smarty here, I just don't know the answer.
>
> > PQftype returns the field type associated with the
> > given field index. The integer returned is an
> > internal coding of the type.
>
> Unless I missed what D'Arcy was getting at, his point was that when
> PQftype tells you the field type is, say, 23, how do you know what
> that means?
Exactly.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
"D'Arcy J.M. Cain" wrote: > > Thus spake Tom Lane > > Hugh Lawson <hglawson@nr.infi.net> writes: > > > I'm just getting started on fiddling with libpq. I am wondering why > > > this passage from man libpq doesn't address this issue? I'm not being > > > a smarty here, I just don't know the answer. > > > > > PQftype returns the field type associated with the > > > given field index. The integer returned is an > > > internal coding of the type. > > > > Unless I missed what D'Arcy was getting at, his point was that when > > PQftype tells you the field type is, say, 23, how do you know what > > that means? do "select * from pg_type where oid=23" and work from there on. The 'internal coding' actually means OID for that type definition row. (Could someone post a patch for docs ?) the base types ids are quite stable and could possibly be found in some .h file, but anything new you add gets o quite random OID. ------------------ Hannu
On Mon, 3 May 1999, D'Arcy J.M. Cain wrote: > Thus spake Tom Lane > > Hugh Lawson <hglawson@nr.infi.net> writes: > > > I'm just getting started on fiddling with libpq. I am wondering why > > > this passage from man libpq doesn't address this issue? I'm not being > > > a smarty here, I just don't know the answer. > > > > > PQftype returns the field type associated with the > > > given field index. The integer returned is an > > > internal coding of the type. > > > > Unless I missed what D'Arcy was getting at, his point was that when > > PQftype tells you the field type is, say, 23, how do you know what > > that means? > > Exactly. Uhhh, <cringe>, <blush>, thanks for the patient education. Boy did I ever miss the point! Programming this is over my head right now, so I'm saving these msgs. Hugh Lawson Greensboro, North Carolina hglawson@nr.infi.net