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. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
