Thread: C++: get value for integral types?
Does anyone know whether it is possible to get a tuple's value as an int, float, bool, etc. using the C++ postgresql library? Getting floats as string representations (via char* GetValue(...)) of the value is not acceptable! Using strings and streams to convert the values to the corresponding integral type may cause problems! Any ideas, workarounds? Is BinaryTuples really not implemnted yet? thanks... __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
On Sun, 10 Nov 2002, Vassil Kriakov wrote:
> Does anyone know whether it is possible to get a tuple's value as an
> int, float, bool, etc. using the C++ postgresql library?
>
> Getting floats as string representations (via char* GetValue(...)) of
> the value is not acceptable! Using strings and streams to convert the
> values to the corresponding integral type may cause problems!
>
> Any ideas, workarounds? Is BinaryTuples really not implemnted yet?
Doesn't the C++ version work? Have you DECLAREd a binary cursor and
used FETCH to get the data? (It works with libpq)
HTH--
-frank
Hi, it would be hard to interpret the binary value. I think it is not specified, how a specific type is represented as a binary value. The programmers guide just tells: "But if PQbinaryTuples() is 1, the value returned by PQgetvalue is the binary representation of the type in the internal format of the backend server". So its internal and platformspecific. It is even hard to get usable type-information. The types are defined in a systemtable (pg_type). But new types are created in some situations, when you just create a new table. I think the safest way to retrieve values in C++ is to convert the stringrepresentation. It might be helpful to define some api-functions to retrieve some integral types (PGgetLong, PGgetDouble). The backendprocess knows better about datatypes. What do you think? Tommi Am Sonntag, 10. November 2002 23:56 schrieb Frank Miles: > On Sun, 10 Nov 2002, Vassil Kriakov wrote: > > Does anyone know whether it is possible to get a tuple's value as an > > int, float, bool, etc. using the C++ postgresql library? > > > > Getting floats as string representations (via char* GetValue(...)) of > > the value is not acceptable! Using strings and streams to convert the > > values to the corresponding integral type may cause problems! > > > > Any ideas, workarounds? Is BinaryTuples really not implemnted yet? > > Doesn't the C++ version work? Have you DECLAREd a binary cursor and > used FETCH to get the data? (It works with libpq) > > HTH-- > > -frank > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de
Exactly, 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!? Using C++ templates (template specialization, to be precise), it would be possible to get any kind of type, system-independent, from the database (as done in libpqxx). However, I have yet to see how they do the actual conversion since pqxx itself is, naturally, based on libpq. -- vassil --- Tommi Maekitalo <t.maekitalo@epgmbh.de> wrote: > Hi, > > it would be hard to interpret the binary value. I think it is not > specified, > how a specific type is represented as a binary value. The programmers > guide > just tells: "But if PQbinaryTuples() is 1, the value returned by > PQgetvalue > is the binary representation of the type in the internal format of > the > backend server". So its internal and platformspecific. It is even > hard to get > usable type-information. The types are defined in a systemtable > (pg_type). > But new types are created in some situations, when you just create a > new > table. > > I think the safest way to retrieve values in C++ is to convert the > stringrepresentation. > > It might be helpful to define some api-functions to retrieve some > integral > types (PGgetLong, PGgetDouble). The backendprocess knows better about > > datatypes. What do you think? > > > Tommi > > Am Sonntag, 10. November 2002 23:56 schrieb Frank Miles: > > On Sun, 10 Nov 2002, Vassil Kriakov wrote: > > > Does anyone know whether it is possible to get a tuple's value as > an > > > int, float, bool, etc. using the C++ postgresql library? > > > > > > Getting floats as string representations (via char* > GetValue(...)) of > > > the value is not acceptable! Using strings and streams to convert > the > > > values to the corresponding integral type may cause problems! > > > > > > Any ideas, workarounds? Is BinaryTuples really not implemnted > yet? > > > > Doesn't the C++ version work? Have you DECLAREd a binary cursor > and > > used FETCH to get the data? (It works with libpq) > > > > HTH-- > > > > -frank > > > > > > ---------------------------(end of > broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister > command > > (send "unregister YourEmailAddressHere" to > majordomo@postgresql.org) > > -- > Dr. Eckhardt + Partner GmbH > http://www.epgmbh.de > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
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.
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
Hi, Am Dienstag, 12. November 2002 18:27 schrieb Vassil Kriakov: > 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. > That's exactly the problem. What if you have different platforms at server-end and client-end? You can't reliable convert a char* to int* or even worse to float*. The better way is to improve the interface to get some usable typedata and an accessorfunction for int, long, double, bool... There is a thread in pgsql-hackers about "protocol change in 7.4", which talks about it. I feel that using ascii-data is the most robust and portable way. Tommi
On 12 Nov 2002 at 9:27, Vassil Kriakov wrote:
> 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.
That's OK..
> 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.
I am still not on it. Say you have a HP-UX system as database server and intel
linux client. Now what does 'printf("%s\n",PQgetvalue())' for a float value
prints on client side?
> If you ask me, retrieving tuples in their _original_ type should be the
> default behavior, and string representation of the data should be
> optional.
That means no more heterogenous client-server. String representation is what
allows such mixed environement.
> The problems with doing things either way are:
> (1) type -> string -> type -> string conversions are not reliable
> (especially for float, double, etc.)
Correct. But not unless you want a format. And it's difficult but not
impossible..
> (2) type casting based on _assumptions_ is not reliable
Casts are not required. Client side is supposed to convert the string value to
appropriate type before using.
> (3) to get binary data, you can only use binary cursors
> (begin; declare x binary cursor for <query>; fetch all in x;)
I don't see a problem.
IMO, the real problem is defining what is binary data. Data with primitive
datatypes like float is not really binary data even though it's stored in
binary.
We should consider binary data as one which postgresql will not touch. Say you
created a structure of 8 floats and create the type. Then postgresql will not
touch it and just store/return it.
Even in that case, if you insert from a client platform, you will get back the
exact values. Why? Because postgresql won't touch it.
In fact, I see the string representation as great advantage in web application.
I retrieve a float but I get back a string. Cool... I just print it in CGI. No
time wasted converting a float to string..;-)
All this is theory because I have never worked on mixed client-server. I hope
it works that way. Let us know if there is something different in actual
behaviour..
Just a thought
Bye
Shridhar
--
QOTD: Silence is the only virtue he has left.