| From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
|---|---|
| To: | "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
| 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 17:28:20 |
| Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA3546D@algol.sollentuna.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> >>>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)
//Magnus
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chris Browne | 2006-05-31 17:51:45 | Re: Possible TODO item: copy to/from pipe |
| Previous Message | Andreas Pflug | 2006-05-31 17:26:47 | Re: Possible TODO item: copy to/from pipe |