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,
Suporte24x7 e Treinamento
