Re: libpq compression

On Fri, Jun 15, 2012 at 07:18:34AM -0500, Merlin Moncure wrote:
> On Fri, Jun 15, 2012 at 5:48 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
> > On Jun15, 2012, at 12:09 , Magnus Hagander wrote:
> >> On Fri, Jun 15, 2012 at 5:52 PM, Florian Pflug <fgp(at)phlo(dot)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?
> >
> > 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.
>
> hm, that's a really excellent point.
>
> merlin
>

I agree and think that the SSL-based compression is an excellent default
compression scheme. The plugable compression approach allows for the
choice of the most appropriate compression implementation based on the
application needs. It really addresses corner cases such as high-
performance system.

Regards,
Ken