From: | PFC <lists(at)peufeu(dot)com> |
---|---|
To: | "Eugene E(dot)" <sad(at)bankir(dot)ru> |
Cc: | "Achilleus Mantzios" <achill(at)matrix(dot)gatewaynet(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-sql(at)postgresql(dot)org |
Subject: | Re: have you feel anything when you read this ? |
Date: | 2006-03-20 16:44:27 |
Message-ID: | op.s6p0sdq2cigqcu@apollo13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Frost | 2006-03-20 17:18:17 | Re: update before drop causes OID problems in transaction? |
Previous Message | Scott Marlowe | 2006-03-20 16:10:30 | Re: have you feel anything when you read this ? |