Re: libpq compression - Mailing list pgsql-hackers

On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug <fgp@phlo.org> wrote:
> On Jun15, 2012, at 12:09 , Magnus Hagander wrote:
>> On Fri, Jun 15, 2012 at 5:52 PM, Florian Pflug <fgp@phlo.org> wrote:
>>> On Jun15, 2012, at 07:50 , Magnus Hagander wrote:
>>>> Second, we also have things like the JDBC driver and the .Net driver
>>>> that don't use libpq. the JDBC driver uses the native java ssl
>>>> support, AFAIK. Does that one support the compression, and does it
>>>> support controlling it?
>>>
>>> Java uses pluggable providers with standardized interfaces for most
>>> things related to encryption. SSL support is provided by JSSE
>>> (Java Secure Socket Extension). The JSSE implementation included with
>>> the oracle JRE doesn't seem to support compression according to the
>>> wikipedia page quoted above. But chances are that there exists an
>>> alternative implementation which does.
>>
>> Yeah, but that alone is IMO a rather big blocker for claiming that
>> this is the only way to do it :( And I think the fact that that
>> wikipedia page doesn't list any other ones, is a sign that there might
>> not be a lot of other choices out there in reality - expecially not
>> opensource…
>
> Hm, but things get even harder for the JDBC and .NET folks if we go
> with a third-party compression method. Or would we require that the
> existence of a free Java (and maybe .NET) implementation of such a
> method would be an absolute must?

As long as a free implementation exists, it can be ported to
Java/.Net. Sure, it takes more work, but it *can be done*.


> The way I see it, if we use SSL-based compression then non-libpq clients
> there's at least a chance of those clients being able to use it easily
> (if their SSL implementation supports it). If we go with a third-party
> compression method, they *all* need to add yet another dependency, or may
> even need to re-implement the compression method in their implementation
> language of choice.

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.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/