On 20-06-2012 17:40, Marko Kreen wrote:
> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug <fgp@phlo.org> wrote:
>> I'm starting to think that relying on SSL/TLS for compression of
>> unencrypted connections might not be such a good idea after all. We'd
>> be using the protocol in a way it quite clearly never was intended to
>> be used...
>
> Maybe, but what is the argument that we should avoid
> on encryption+compression at the same time?
>
> AES is quite lightweight compared to compression, so should
> be no problem in situations where you care about compression.
>
If we could solve compression problem without AES that will turn things
easier. Compression-only via encryption is a weird manner to solve the problem
in the user's POV.
> RSA is noticeable, but only for short connections.
> Thus easily solvable with connection pooling.
>
RSA overhead is not the main problem. SSL/TLS setup is.
> And for really special compression needs you can always
> create a UDF that does custom compression for you.
>
You have to own the code to modify it; it is not always an option.
> So what exactly is the situation we need to solve
> with postgres-specific protocol compression?
>
Compression only support. Why do I need to set up SSL/TLS just for compression?
IMHO SSL/TLS use is no different from relying in another library to handle
compression for the protocol and more it is compression-specific. That way, we
could implement another algorithms in such library without needing to modify
libpq code. Using SSL/TLS you are bounded by what SSL/TLS software products
decide to use as compression algorithms. I'll be happy to maintain the code
iif it is postgres-specific or even as close as possible to core.
-- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento,
Suporte24x7 e Treinamento
