Albe Laurenz wrote: > Tom Lane wrote: > > 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 agree that it is sensible to have the setting on the client, > and that there should not be too many GUCs. > > >> 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". > > In a way, yes, except that I think that "wrong" is exaggerated. > As DBA I like to have an option to control things from the server > end -- if that's laziness, so be it. > > So, should I forget about the GUC or is anybody going to back me? > > I'd still be willing to write a patch for a client-only solution.
Agreed. There is clearly a win in turning off SSL compression for certain workloads, and if people think the client is the right location, then let's do it there. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers