"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.
> I could go and try to convince Npgsql and JDBC to accept patches to
> do that on the client side, but that would be more effort than I
> want to invest. But then there's still closed source software like
> Devart dotConnect...
This argument reads as nothing except "I'm too lazy to solve it right,
so I want you to accept a wrong solution".
regards, tom lane