Re: libpq compression

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 14:56:15
Message-ID: 4FDB4D0F.6090206@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15.06.2012 17:39, Magnus Hagander wrote:
> On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug<fgp(at)phlo(dot)org> wrote:
>> 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.
>
> I only partially agree. If there *is* no third party SSL libary that
> does support it, then they're stuck reimplementing an *entire SSL
> library*, which is surely many orders of magnitude more work, and
> suddenly steps into writing encryption code which is a lot more
> sensitive.

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.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2012-06-15 14:58:25 Re: libpq compression
Previous Message Magnus Hagander 2012-06-15 14:54:16 Re: [COMMITTERS] pgsql: New SQL functons pg_backup_in_progress() and pg_backup_start_tim