On Fri, Jun 15, 2012 at 10:56 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 15.06.2012 17:39, Magnus Hagander wrote: >> >> On Fri, Jun 15, 2012 at 6:48 PM, Florian Pflug<f...@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? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
