From: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible TODO item: copy to/from pipe |
Date: | 2006-05-31 19:55:17 |
Message-ID: | C0A3B335.D1F4%dpage@vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31/5/06 18:28, "Magnus Hagander" <mha(at)sollentuna(dot)net> wrote:
>>>>> 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.
>>>>
>>>> Forgot to mention:
>>>> COPY COMPRESSED was also meant to introduce a portable
>> format that's
>>>> efficient for both text and binary data. Relying on some external
>>>> XYZzip version seems not too portable to me.
>>>
>>>
>>> It does have that advantage. Gzip and others are not particularly
>>> Windows friendly for example.
>>
>> ... as most windows programs are pipe agnostic.
>
> For the record, gzip on win32 works perfectly fine both as a separate
> program and running in a pipe. No problem at all. The only issue is that
> it's not available by default. (And possible issues with programs
> launching it that don't know how to deal with windows style directory
> naming)
Exactly my point; how many production Windows servers do you have with gzip
anywhere near them? Andreas' point about pipes is also valid though - it's
simply not the norm on Windows as I found when we were porting Slony
(more.exe barfs at >8MB being pipe in).
Regards, Dave.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-05-31 19:58:12 | Re: Possible TODO item: copy to/from pipe |
Previous Message | Greg Stark | 2006-05-31 19:49:21 | Re: error-free disabling of individual child partition |