If you declared a binary cursor (see example prog in postgresql tech
doc. in libpq section), PQgetvalue() will return the "internal backend
server binary representation" of the value you are getting. So if you
were getting something that's an int, PQgetvalue() will return pointer
to memory where your int is in binary format.
Hoping that the backend server's way of storing int, float, bool, etc.
is the same as at the client-end, you can re-interpret the char* to a
float* or int*, etc.
If you ask me, retrieving tuples in their _original_ type should be the
default behavior, and string representation of the data should be
optional.
The problems with doing things either way are:
(1) type -> string -> type -> string conversions are not reliable
(especially for float, double, etc.)
(2) type casting based on _assumptions_ is not reliable
(3) to get binary data, you can only use binary cursors
(begin; declare x binary cursor for <query>; fetch all in x;)
If anyone knows any alternatives, please let me know.
vassil
--- Shridhar Daithankar <shridhar_daithankar@persistent.co.in> wrote:
> On 11 Nov 2002 at 11:44, Vassil Kriakov wrote:
>
> > It makes me very uneasy doing a (int *) on char* PQgetvalue(...)
> just
> > because i EXPECT it to give me an int type. And of course the
> question
> > of user-defined types!?
>
> I went thr. the entire thread quoted in this mail. One thing I don't
> understand
> is casting int* on a string.
>
> I always did an atoi(PQgetvalue()). I thought that was the way.
> What's the
> problem exactly?
>
> Dunno about binary tuples. Never used it..
>
> Bye
> Shridhar
>
> --
> Tussman's Law: Nothing is as inevitable as a mistake whose time has
> come.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
