From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCH] COPY .. COMPRESSED |
Date: | 2013-01-14 03:34:33 |
Message-ID: | 25178.1358134473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Attached is a patch to add a 'COMPRESSED' option to COPY which will
> cause COPY to expect a gzip'd file on input and which will output a
> gzip'd file on output. Included is support for backend COPY, psql's
> \copy, regression tests for both, and documentation.
I don't think it's a very good idea to invent such a specialized option,
nor to tie it to gzip, which is widely considered to be old news.
There was discussion (and, I think, a patch in the queue) for allowing
COPY to pipe into or out of an arbitrary shell pipe. Why would that not
be enough to cover this use-case? That is, instead of a hard-wired
capability, people would do something like COPY TO '| gzip >file.gz'.
Or they could use bzip2 or whatever struck their fancy.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2013-01-14 03:42:09 | Re: count(*) of zero rows returns 1 |
Previous Message | Tom Lane | 2013-01-14 03:27:12 | Re: Possible PANIC in PostPrepare_Locks |