On 15.06.2012 17:58, Magnus Hagander wrote:
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?
Umm, then you use a real SSL libray, not the dummy one?
--
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
