Stephan Szabo wrote:
On Wed, 5 Apr 2006, Eugene E. wrote:
Stephan Szabo wrote:
On Tue, 4 Apr 2006, Eugene E. wrote:
Stephan Szabo wrote:
On Fri, 31 Mar 2006, Eugene E. wrote:
Peter Eisentraut wrote:
Eugene E. wrote:
the problem is: you'll get this four byte sequence '\000' _instead_
of NUL-byte anyway.
What you seem to be missing is that PostgreSQL data can be represented
in textual and in binary form. What you in psql is the textual form.
If you want the binary form you need to select it. Then you can pass
the exact bytes back and forth.
your sentence is not true.
I can not select exact bytes even if i use BYTEA type
No, that is still using the textual form. If you use PQexecParams and set
the last argument to show you want binary data, you should get binary
data.
ok
then i am using PQexecParams
the following tiny program shows a wonderful lameness...
What lameness? The fact that you're trying to use a binary (network order
maybe) integer as a string? That's not the fault of PQexecParams but
of the code calling it.
You're right !
That's is not a fault of PQexecParams at all. That's the fault of its
design. (I pretty know why an integer has been not displayed, but why
they designed this function that way ? i do not know)
It'd be nice for ease of use to be able to say, give me this
column (the integer) as a string and this column (the bytea) as binary,
I always want to retrieve TEXT (and mostly INT) in TEXTUAL-FORM, and
BYTEA always in BINARY-FORM. (at least by defaul)
WHY SHOULD I RETRIVE A SINGLE BYTEA FIELD IN A SEPARATE QUERY ???
Look: if i define a field as of type BYTEA, doesn't it mean the field
tends to store binary data ? If does, then WHY they (by default) convert
its value to TEXTUAL-FORM which is not needed by default -- i already
inform the server: "i want some BINARY to in and out" when i have
choosed the type BYTEA
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
