Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 39BBACE6EC for ; Fri, 15 Jun 2012 11:56:40 -0300 (ADT) Received: from exprod7og126.obsmtp.com ([64.18.2.206]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SfXx0-0003Kr-Ct for pgsql-hackers@postgresql.org; Fri, 15 Jun 2012 14:56:39 +0000 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT9tNF7PIwZUQkbkuJAE439TtXoQDurRT@postini.com; Fri, 15 Jun 2012 07:56:38 PDT Received: by lahc1 with SMTP id c1so2331400lah.4 for ; Fri, 15 Jun 2012 07:56:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=zJaPvOQXBvBYQ1sEi6BfRgMEVuyTRZGhl1ItpZ20yNI=; b=mZEfC0VTI5zv33VUJfjRDBXCRzm7KL1dEoaESmdvhwgV3oQFTRPRNy0/uLRrVc3QZ6 4WDcw4Tn2DJXbCKeWhyUub+FBlzbMc4vlBloBfBvFxnLKzw0W0g4wvyQDIvmxkSdLmRV 80IRQmyznZHNtafaLC3E58AWLYLB5NDvLUaw6aN8TQwQKlE15HWBdEVgDnSwfufWfw42 SgnOhfTRt2tPsbt5kdfntjUVZ2Dx+kpH8S+zrp/3dWBK/EfVfXashVD+Hr+hRqXvHCWO RYmCT1zuH7TZ3QcS6rmHTAZ9I8K8VEYvFyIHv3sxXsTePnpgiQwoDGzArCuHrfwDkbq/ Fkvg== Received: by 10.112.45.230 with SMTP id q6mr2711861lbm.94.1339772181963; Fri, 15 Jun 2012 07:56:21 -0700 (PDT) Received: from [192.168.1.100] (dsl-hkibrasgw2-ff6cc300-200.dhcp.inet.fi. [88.195.108.200]) by mx.google.com with ESMTPS id h9sm6350371lbi.9.2012.06.15.07.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 07:56:20 -0700 (PDT) Message-ID: <4FDB4D0F.6090206@enterprisedb.com> Date: Fri, 15 Jun 2012 17:56:15 +0300 From: Heikki Linnakangas 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 CC: Florian Pflug , Bruce Momjian , Tom Lane , Euler Taveira , Pgsql Hackers 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> <22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl16AOYem9u41zs9lzX4tYZQyKIwiKw3rqaLpWZSbynez7gGRtut84XV3hlUL2nRB8T/GY4 X-Pg-Spam-Score: -4.2 (----) X-Archive-Number: 201206/718 X-Sequence-Number: 209558 On 15.06.2012 17:39, Magnus Hagander wrote: > On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug 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