> 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
