Message-ID: <447DD1D7.20001@pse-consulting.de>
Date: Wed, 31 May 2006 19:26:47 +0200
From: Andreas Pflug <pgadmin@pse-consulting.de>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: "Joshua D. Drake" <jd@commandprompt.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>,  pgsql-hackers@postgresql.org
Subject: Re: Possible TODO item: copy to/from pipe
References: <12436.1149087794@sss.pgh.pa.us>
	<447DB844.6010507@pse-consulting.de>
	<447DB910.2020607@pse-consulting.de>
	<13208.1149093007@sss.pgh.pa.us>
	<447DCFAF.4070308@commandprompt.com>
In-Reply-To: <447DCFAF.4070308@commandprompt.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joshua D. Drake wrote:
>>
>> I dislike putting this into the backend precisely because it's trying to
>> impose a one-size-fits-all compression solution.  Someone might wish to
>> use bzip2 instead of gzip, for instance, or tweak the compression level
>> options of gzip.  It's trivial for the user to do that if the
>> compression program is separate, not trivial at all if it's wired into
>> COPY.  Also, a pipe feature would have uses unrelated to compression,
>> such as on-the-fly analysis or generation of data.
> 
> 
> It seems that it would be better to have the options within pg_dump 
> which would give the most flexibility.

What about all other client tools?

My COPY WITH COMPRESSION is not the same as taking a copy file and 
zipping it; it creates a copy file with BinarySignature that has 
compressed bytes in the data part, thus it can be handled by any client 
app that can stream binary copy files from/to the server.

Regards,
Andreas