X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8F5509FA5F0 for ; Wed, 31 May 2006 12:37:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 57733-09 for ; Wed, 31 May 2006 12:37:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by postgresql.org (Postfix) with ESMTP id BA6799FA5DD for ; Wed, 31 May 2006 12:37:43 -0300 (ADT) Received: from [84.143.7.134] (helo=pse.dyndns.org) by mrelayeu.kundenserver.de (node=mrelayeu10) with ESMTP (Nemesis), id 0ML31I-1FlSlS0SSa-0006HI; Wed, 31 May 2006 17:37:42 +0200 Received: from pse1 ([192.168.0.3]) by pse.dyndns.org with esmtp (Exim 4.44) id 1FlSlQ-0004pI-SQ; Wed, 31 May 2006 17:37:40 +0200 Message-ID: <447DB844.6010507@pse-consulting.de> Date: Wed, 31 May 2006 17:37:40 +0200 From: Andreas Pflug User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Lane CC: pgsql-hackers@postgreSQL.org Subject: Re: Possible TODO item: copy to/from pipe References: <12436.1149087794@sss.pgh.pa.us> In-Reply-To: <12436.1149087794@sss.pgh.pa.us> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:0ce7ee5c3478b8d72edd8e05ccd40b70 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/1330 X-Sequence-Number: 84195 Tom Lane wrote: > After re-reading what I just wrote to Andreas about how compression of > COPY data would be better done outside the backend than inside, it > struck me that we are missing a feature that's fairly common in Unix > programs. Perhaps COPY ought to have the ability to pipe its output > to a shell command, or read input from a shell command. Maybe something > like > > COPY mytable TO '| gzip >/home/tgl/mytable.dump.gz'; > > (I'm not wedded to the above syntax, it's just an off-the-cuff thought.) > > Of course psql would need the same capability, since the server-side > copy would still be restricted to superusers. Won't help too much, until gzip's output is piped back too, so a replacement for COPY .. TO STDOUT COMPRESSED would be COPY ... TO '| /bin/gzip |' STDOUT, to enable clients to receive the reduced stuff. But clients should be agnostic of server side installed tools, and probably not be able to address them directly. Sounds like a potential security issue. Regards, Andreas