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, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers