From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, 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 16:03:08 |
Message-ID: | 4FDB5CBC.1030701@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15.06.2012 18:28, Magnus Hagander wrote:
> On Fri, Jun 15, 2012 at 11:24 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> On 15.06.2012 17:58, Magnus Hagander wrote:
>>>
>>> On Fri, Jun 15, 2012 at 10:56 PM, Heikki Linnakangas
>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>>
>>>> You could write a dummy SSL implementation that only does compression,
>>>> not
>>>> encryption. Ie. only support the 'null' encryption method. That should be
>>>> about the same amount of work as writing an implementation of compression
>>>> using whatever protocol we would decide to use for negotiating the
>>>> compression.
>>>
>>> Sure, but then what do you do if you actually want both?
>>
>> Umm, then you use a real SSL libray, not the dummy one?
>
> But (in this scenario, and so far nobody has proven it to be wrong)
> there exists no real SSL library that does support compression.
Oh, I see. Then you're screwed. But I think the right solution to that
is to write/extend a Java SSL implementation to support compression, not
to invent our own in PostgreSQL. The JDK is open source nowadays.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-06-15 16:18:07 | Re: COMMENT on function's arguments |
Previous Message | Ryan Kelly | 2012-06-15 15:58:55 | Re: libpq compression |