On Mon, Mar 14, 2022 at 1:21 PM Robert Haas <robertmh...@gmail.com> wrote: > There's some appeal to that, but one downside is that it means that > the client can't be used to fetch data that is compressed in a way > that the server knows about and the client doesn't. I don't think > that's great. Why should, for example, pg_basebackup need to be > compiled with zstd support in order to request zstd compression on the > server side? If the server knows about the brand new > justin-magic-sauce compression algorithm, maybe the client should just > be able to request it and, when given various .jms files by the > server, shrug its shoulders and accept them for what they are. That > doesn't work if -Fp is involved, or similar, but it should work fine > for simple cases if we set things up right.
Concretely, I propose the attached patch for v15. It renames the newly-added COMPRESSION_LEVEL option to COMPRESSION_DETAIL, introduces a flexible syntax for options along the lines you proposed, and adjusts things so that a client that doesn't support a particular type of compression can still request that type of compression from the server. I think it's important to do this for v15 so that we don't end up with backward-compatibility problems down the road. -- Robert Haas EDB: http://www.enterprisedb.com
v1-0001-Replace-BASE_BACKUP-COMPRESSION_LEVEL-option-with.patch
Description: Binary data
