On Tue, May 14, 2024 at 3:22 PM Jacob Burroughs <jburrou...@instructure.com> wrote: > What if we went with: > Server side: > * `libpq_compression=on` (I just want everything the server supports > available; probably the most common case) > * `libpq_compression=off` (I don't want any compression ever with this server) > * `libpq_compression=lzma;gzip` (I only want these algorithms for > whatever reason) > * `libpq_compression=lzma:client_to_server=off;gzip:server_to_client=off` > (I only want to send data with lzma and receive data with gzip) > Client side: > *`compression=on` (I just want compression; pick sane defaults > automatically for me; probably the most common case) > * `compression=off` (I don't want any compression) > * `compression=lzma;gzip` (I only want these algorithms for whatever reason) > * `compression=lzma:client_to_server=off;gzip:server_to_client=off` (I > only want to receive data with lzma and send data with gzip) > > `client_to_server`/`server_to_client` is a bit verbose, but it's very > explicit in what it means, so you don't need to reason about who is > sending/receiving/etc in a given context, and a given config string > applied to the server or the client side has the same effect on the > connection.
IMHO, that's a HUGE improvement. But: * I would probably change is the name "libpq_compression", because even though we have src/backend/libpq, we typically use libpq to refer to the client library, not the server's implementation of the wire protocol. I think we could call it connection_encryption or wire_protocol_encryption or something like that, but I'm not a huge fan of libpq_compression. * I would use commas, not semicolons, to separate items in a list, i.e. lzma,gzip not lzma;gzip. I think that convention is nearly universal in PostgreSQL, but feel free to point out counterexamples if you were modelling this on something. * libpq_compression=lzma:client_to_server=off;gzip:server_to_client=off reads strangely to me. How about making it so that the syntax is like this: libpq_compression=DEFAULT_VALUE_FOR_BOTH_DIRECTIONS:client_to_server=OVERRIDE_FOR_THIS_DIRECTION:servert_to_client=OVERRIDE_FOR_THIS_DIRECTION With all components being optional. So this example could be written in any of these ways: libpq_compression=lzma;server_to_client=gzip libpq_compression=gzip;client_to_server=lzma libpq_compression=server_to_client=gzip;client_to_server=lzma libpq_compression=client_to_server=lzma;client_to_server=gzip And if I wrote libpq_compression=server_to_client=gzip that would mean send data to the client using gzip and in the other direction use whatever the default is. -- Robert Haas EDB: http://www.enterprisedb.com