Re: Disable OpenSSL compression - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Disable OpenSSL compression
Date
Msg-id CAFNqd5X5BFEGayNAkiV=Vn6zYd8rTp=O8zc6rSHsCQoeR6ehnQ@mail.gmail.com
Whole thread Raw
In response to Re: Disable OpenSSL compression  ("ktm@rice.edu" <ktm@rice.edu>)
Responses Re: Disable OpenSSL compression
List pgsql-hackers
On Tue, Nov 8, 2011 at 11:06 AM, ktm@rice.edu <ktm@rice.edu> wrote:
> I think that JDBC and Npgsql should also support disabling compression.

That's the *real* problem here...

You're quite right that if we allow controlling this on the libpq
side, it is surely desirable to allow controlling this via JDBC,
Npgsql, and other mechanisms people may have around.  (There are
native protocol implementations for Common Lisp and Go, for instance.
They may not be particularly important, )

Unfortunately, each protocol implementation is independent, which
really is the nature of the beast, which includes:
a) The code of the implementation,
b) Release of the implementation,
c) Packaging of releases into software distributions.

With that series of complications, I wonder if maybe the right place
to control this is pg_hba.conf.  That has the merit of centralizing
control in such a way that it would apply commonly to
libpq/JDBC/Npgsql/..., though with the demerit that the control does
not take place on the client side, which is desirable.

I wonder how many SSL parameters there are which would be worth trying
to have available.  I expect we'd benefit from looking at all the
relevant ones at once, so as to not have the problem of hacking "one
more" into place and perhaps doing it a bit differently each time.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


pgsql-hackers by date:

Previous
From: Sushant Sinha
Date:
Subject: Re: lexemes in prefix search going through dictionary modifications
Next
From: Robert Haas
Date:
Subject: Re: [v9.2] Object access hooks with arguments support (v1)