On Wed, Jan 16, 2013 at 06:19:09PM -0500, Robert Haas wrote:
> On Tue, Jan 15, 2013 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I find the argument that this supports compression-over-the-wire to be
> > quite weak, because COPY is only one form of bulk data transfer, and
> > one that a lot of applications don't ever use. If we think we need to
> > support transmission compression for ourselves, it ought to be
> > integrated at the wire protocol level, not in COPY.
> >
> > Just to not look like I'm rejecting stuff without proposing
> > alternatives, here is an idea about a backwards-compatible design for
> > doing that: we could add an option that can be set in the connection
> > request packet. Say, "transmission_compression = gzip".
>
> But presumably this would transparently compress at one end and
> decompress at the other end, which is again a somewhat different use
> case. To get compressed output on the client side, you have to
> decompress and recompress. Maybe that's OK, but it's not quite the
> same thing.
Is there a TODO here?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +