On 20-06-2012 17:40, Marko Kreen wrote: > On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug <f...@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, 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
