Re: C++: get value for integral types?

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.