Tom Lane wrote:
> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> > Tom Lane wrote:
> >> A GUC is entirely, completely, 100% the wrong answer. It has no way
> >> to deal with the fact that some clients may need compression and others
> >> not.
>
> > You can force a certain SSL cipher on the client, why not a compression
> > setting?
>
> To my mind, the argument for the ssl_cipher setting is to allow the DBA
> to enforce a site-wide security policy to the effect of "we consider
> only these ciphers strong enough for production use". It's a pretty
> weak argument (especially since the setting is not cognizant of where
> the connection is coming from), but at least it's an argument.
>
> There's no comparable security argument for an ssl_compression setting.
> If anything, a security-minded DBA might wish to insist on compression
> being *on*, but you aren't proposing to give him control in that
> direction (and AFAICT openssl doesn't offer a force-on flag for it).
>
> But in any case, my objection is that there's no adequate use-case
> for this GUC, because it's much more sensible to set it from the client
> side. We have too many GUCs already --- Josh B regularly goes on the
> warpath looking for ones we can remove. This one should never get in
> there to start with.
How is the compression connection parameter set? It seems odd for it to
be compiled into the application because the application could be run on
different networks. I don't know of any way to inject connection
options from outside the application like libpq's PGOPTIONS. Would we
add a libpq environment variable for this, like PGUSER?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +