Re: [PATCH] COPY .. COMPRESSED

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] COPY .. COMPRESSED
Date: 2013-01-14 14:23:31
Message-ID: CA+U5nMKx3BtKyk_XV7D=YuVJ+cxX+9-_OpjzsdFkAObLd_fZ8w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14 January 2013 13:43, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Tom,
>
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> 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.
>
> We're already using gzip/zlib for pg_dump/pg_restore, so it was simple
> and straight-forward to add and would allow utilizing this option while
> keeping the custom dump format the same.

Both thoughts are useful, I think.

There is a new option being added to pre/post process data, so it
seems like the best way to add new features - in general.

Specifically, we do support compressed output so a simple patch to
allow re-loading of the compressed data we generate does seem sensible
and reasonable.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-01-14 15:16:31 Re: common fe/be library (was Re: [PATCH] binary heap implementation)
Previous Message Stephen Frost 2013-01-14 13:43:11 Re: [PATCH] COPY .. COMPRESSED