Message-ID: <4FDB5396.4050402@enterprisedb.com>
Date: Fri, 15 Jun 2012 18:24:06 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Magnus Hagander <magnus@hagander.net>
CC: Florian Pflug <fgp@phlo.org>, Bruce Momjian <bruce@momjian.us>,
	Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira <euler@timbira.com>,
	Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us>
	<4FD9E70B.9040607@timbira.com> <11502.1339699384@sss.pgh.pa.us>
	<20120615021938.GA21704@momjian.us>
	<CABUevEyv4T+1gR6_Uqm_1qUD9PNDg6UdXbJhwHZgFi9hpQQ6NQ@mail.gmail.com>
	<F3B8BAA6-23E9-423A-A7D1-D2E14769F326@phlo.org>
	<CABUevExi-cJ6AvF2kDOy+qQsB+0JHofrcvVmNVoJ2HziZMMaAg@mail.gmail.com>
	<22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org>
	<CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<4FDB4D0F.6090206@enterprisedb.com>
	<CABUevEyYgnO_zvQT2f8N2ZRZeZ-ZNeW4HxF9AAC3LJqRQrbWUg@mail.gmail.com>
In-Reply-To: 
 <CABUevEyYgnO_zvQT2f8N2ZRZeZ-ZNeW4HxF9AAC3LJqRQrbWUg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 15.06.2012 17:58, Magnus Hagander wrote:
> On Fri, Jun 15, 2012 at 10:56 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> On 15.06.2012 17:39, Magnus Hagander wrote:
>>>
>>> On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug<fgp@phlo.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.
>
> Sure, but then what do you do if you actually want both?

Umm, then you use a real SSL libray, not the dummy one?

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