|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Stephen Frost <sfrost(at)snowman(dot)net>|
|Cc:||Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: [PATCH] COPY .. COMPRESSED|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>> And this leads to support-my-compression-binary-of-the-day mess. Why
>> not just allow them to do '|compression-binary'?
> The popen patch doesn't support the '|compression-binary' option through
> the FE protocol. Even if it did, it would only be available for
> superusers as we can't allow regular users to run arbitrary commands on
> the server-side.
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".
regards, tom lane
|Next Message||Robert Haas||2013-01-15 21:54:51||Re: unlogged tables vs. GIST|
|Previous Message||David E. Wheeler||2013-01-15 21:36:30||Re: json api WIP patch|