From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira <euler(at)timbira(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-15 12:18:34 |
Message-ID: | CAHyXU0wF9oDrMJgarH36V7sCv-iOuXLui1u-ar0eMwUUAXp6sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ants Aasma | 2012-06-15 13:22:49 | Re: [PATCH] Lazy hashaggregate when no aggregation is needed |
Previous Message | Robert Haas | 2012-06-15 12:16:59 | Re: [COMMITTERS] pgsql: New SQL functons pg_backup_in_progress() and pg_backup_start_tim |