To: "Eugene E." <sad@bankir.ru>
Cc: "Achilleus Mantzios" <achill@matrix.gatewaynet.com>,
	"Peter Eisentraut" <peter_e@gmx.net>, pgsql-sql@postgresql.org
Subject: Re: have you feel anything when you read this ?
References: <Pine.LNX.4.44.0603201522410.22894-100000@matrix.gatewaynet.com>
	<441EA0A7.8030601@bankir.ru> <op.s6pt28eacigqcu@apollo13>
	<441EC1CC.4070300@bankir.ru>
Message-ID: <op.s6p0sdq2cigqcu@apollo13>
Date: Mon, 20 Mar 2006 17:44:27 +0100
From: PFC <lists@peufeu.com>
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
In-Reply-To: <441EC1CC.4070300@bankir.ru>
User-Agent: Opera M2/8.51 (Linux, build 1462)


> 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