On 14-06-2012 02:19, Tom Lane wrote:
> I still think that pushing this off to openssl (not an ssh tunnel, but
> the underlying transport library) would be an adequate solution.
> If you are shoving data over a connection that is long enough to need
> compression, the odds that every bit of it is trustworthy seem pretty
> small, so you need encryption too.
>
I don't want to pay the SSL connection overhead. Also I just want compression,
encryption is not required. OpenSSL give us encryption with/without
compression; we need an option to obtain compression in non-SSL connections.
> We do need the ability to tell openssl to use compression. We don't
> need to implement it ourselves, nor to bring a bunch of new library
> dependencies into our builds. I especially think that importing bzip2
> is a pretty bad idea --- it's not only a new dependency, but bzip2's
> compression versus speed tradeoff is entirely inappropriate for this
> use-case.
>
I see, the idea is that bzip2 would be a compiled-in option (not enabled by
default) just to give another compression option. I don't have a strong
opinion about including it as another dependency. We already depend on zlib
and implementing compression using it won't add another dependency.
What do you think about adding a hook at libpq to load an extension that does
the compression? That way we don't add another dependency at libpq and also a
lot of extensions could be coded to cover a variety of algorithms without
putting us in trouble because of patent infringement.
-- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento