On Fri, Jun 15, 2012 at 5:48 AM, Florian Pflug <f...@phlo.org> wrote: > On Jun15, 2012, at 12:09 , Magnus Hagander wrote: >> On Fri, Jun 15, 2012 at 5:52 PM, Florian Pflug <f...@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? > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
