I wrote:
the problem is: you'll get this four byte sequence '\000' _instead_
of NUL-byte anyway.
You wrote:
Your client library should take care of escaping and de-escaping.
We both agree as you see.
Then i am asking:
WHY should a client take care of de-escaping ? Why not to get his data
unchanged ?
I can understand why you say that for something as simple as a BYTEA, but
if the value to be passed to the client is an ARRAY of geometric types or
something, you gonna need an open, platform-agnostic exchange format
between the way postgres internally represents it and the way the client
represents it (in my case, a python list containing instances of python
classes representing boxes, etc, it'll be different for every language).
Exporting data from postgres in binary is only useful to C programmers
who can import the required struct definitions, and you still have to
manage the format, it's just that you walk struct's instead of unescaping
\'s
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
