On Tue, May 14, 2024 at 5:21 PM Jacob Burroughs <jburrou...@instructure.com> wrote: > The reason for both the semicolons and for not doing this is related > to using the same specification structure as here: > https://www.postgresql.org/docs/current/app-pgbasebackup.html > (specifically the --compress argument).
I agree with that goal, but I'm somewhat confused by how your proposal achieves it. You had libpq_compression=lzma:client_to_server=off;gzip:server_to_client=off, so how do we parse that? Is that two completely separate specifications, one for lzma and one for gzip, and each of those has one option which is set to off? And then they are separated from each other by a semicolon? That actually does make sense, and I think it may do a better job allowing for compression options than my proposal, but it also seems a bit weird, because client_to_server and server_to_client are not really compression options at all. They're framing when this compression specification applies, rather than what it does when it applies. In a way it's a bit like the fact that you can prefix a pg_basebackup's --compress option with client- or server- to specify where the compression should happen. But we can't quite reuse that idea here, because in that case there's no question of doing it in both places, whereas here, you might want one thing for upstream and another thing for downstream. > Alternatively, we could have `connection_compression`, > `connection_compression_server_to_client`, and > `connection_compression_client_to_server` as three separate GUCs (and > on the client side `compression`, `compression_server_to_client`, and > `compression_client_to_server` as three separate connection > parameters), where we would treat `connection_compression` as a > default that could be overridden by an explicit > client_to_server/server_to_client. That creates the slightly funky > case where if you specify all three then the base one ends up unused > because the two more specific ones are being used instead, but that > isn't necessarily terrible. On the server side we *could* go with > just the server_to_client and client_to_server ones, but I think we > want it to be easy to use this feature in the simple case with a > single libpq parameter. I'm not a fan of three settings; I could go with two settings, one for each direction, and if you want both you have to set both. Or, another idea, what if we just separated the two directions with a slash, SEND/RECEIVE, and if there's no slash, then it applies to both directions. So you could say connection_compression='gzip:level=9/lzma' or whatever. But now I'm wondering whether these options should really be symmetric on the client and server sides? Isn't it for the server just to specify a list of acceptable algorithms, and the client to set the compression options? If both sides are trying to set the compression level, for example, who wins? -- Robert Haas EDB: http://www.enterprisedb.com
