Re: Refactoring of compression options in pg_basebackup - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Refactoring of compression options in pg_basebackup
Date
Msg-id CA+TgmoZTQpqboHrVJiqDNhkGMa1U-VJN6R_KcSFLL42xrytpFg@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring of compression options in pg_basebackup  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Refactoring of compression options in pg_basebackup
List pgsql-hackers
On Mon, Jan 17, 2022 at 8:36 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Mon, Jan 17, 2022 at 12:48:12PM -0500, Robert Haas wrote:
> > Alvaro's proposal is fine with me. I don't see any value in replacing
> > --compress with --compression. It's longer but not superior in any way
> > that I can see. Having both seems worst of all -- that's just
> > confusing.
>
> Okay, that looks like a consensus, then.  Robert, would it be better
> to gather all that on the thread that deals with the server-side
> compression?  Doing that here would be fine by me, with the option to
> only specify the client.  Now it would be a bit weird to do things
> with only the client part and not the server part :)

I think it could make sense for you implement
--compress=METHOD[:LEVEL], keeping -z and -Z N as synonyms for
--compress=gzip and --compress=gzip:N, and with --compress=N being
interpreted as --compress=gzip:N. Then I'll generalize that to
--compress=[{client|server}-]METHOD[:LEVEL] on the other thread. I
think we should leave it where, if you don't say either client or
server, you get client, because that's the historical behavior.

If that doesn't work for you, please let me know what you would prefer.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Add last commit LSN to pg_last_committed_xact()
Next
From: Christoph Heiss
Date:
Subject: Re: [PATCH] Add reloption for views to enable RLS