Tom Lane wrote: >>> Is the following proposal acceptable: >>> >>> - Add a GUC ssl_compression, defaulting to "on". >>> - Add a client option "sslcompression" and an environment variable >>> PGSSLCOMPRESSION, defaulting to "1".
> 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. If you leave the GUC at its default value, you can control compression on the client side. You can force a certain SSL cipher on the client, why not a compression setting? > It should be a client option, full stop. The fact that that will be > more work to implement does not make "kluge it at the server" the right > answer. 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... In my environment it would make sense to control the setting on the server side, because all our database clients connect via LAN, and network bandwidth is not the bottleneck in our database applications. Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
