On 15-06-2012 11:39, Magnus Hagander wrote: > As long as a free implementation exists, it can be ported to > Java/.Net. Sure, it takes more work, but it *can be done*. > Good point. IMHO, if there isn't a solution that cover all PostgreSQL (it seems it is not), we should pick the most appropriate one for *libpq* and let other drivers implement it at their time.
> I only partially agree. If there *is* no third party SSL libary that > does support it, then they're stuck reimplementing an *entire SSL > library*, which is surely many orders of magnitude more work, and > suddenly steps into writing encryption code which is a lot more > sensitive. Basically if they have to do that, then they're stuck > *never* being able to fix the problem. > > If we can prove such a third party library *exists*, that makes it > different. But from what I can tell so far, I haven't seen a single > one - let alone one that supports compression. > Using SSL-based compression could be a solution but I would like to emphasize that (i) I'm obligated to use cryptography library to compress data, (ii) I'm paying the price for SSL overhead and (iii) it will confuse people when we said that for compression we need a SSL connection or (iv) even transform the libpq communication code into a spaghetti to support compression using SSL in non-SSL connections). I see the point in not adding another dependencies or reinventing the wheel but I see more drawbacks than benefits in adopting a SSL-based compression. I like the Farina's idea in supporting compression outside libpq but I'm ok with adding a standard algorithm for compression (problem is that in the future others could want to add another interesting compression algorithms). -- Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers