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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
