Re: Refactoring of compression options in pg_basebackup

On Mon, Jan 17, 2022 at 8:41 AM Alvaro Herrera <alvherre@alvh.no-ip.org>
wrote:

> On 2022-Jan-17, Robert Haas wrote:
>
> > Of the two
> > alternatives that you propose, I prefer --compress=["server-"]METHOD
> > and --compression-level=NUMBER to having both
> > --client-compression-level and --server-compression-level. To me,
> > that's still a bit more surprising than my proposal, because having
> > the client compress stuff and having the server compress stuff feel
> > like somewhat different kinds of things ... but it's unsurprising that
> > I like my own proposal, and what really matters is that we converge
> > relatively quickly on something we can all live with.
>
> I think having a single option where you specify everything is simpler.
> I propose we accept these forms:
>
> --compress=[{server,client}-]method[:level]     new in 15
> --compress=level                (accepted by 14)
> -Z level                        (accepted by 14)
> -z                              (accepted by 14)
>

I am also in favor of this option.  Whether this is better than deprecating
--compress and introducing --compression I am having trouble deciding.  My
personal preference is to add --compression and leave --compress alone and
deprecated; but we don't usually do anything with deprecations and having
users seeing both --compress and --compression out in the wild, even if
never at the same time, is bound to elicit questions (though so is seeing
--compress with "number only" rules and "composite value" rules...)


> This way, compatibility with the existing release is maintained; and we
> introduce all the new functionality without cluttering the interface.
>

I would still "clutter" the interface with:

--compress-method
--compress-options (extending from my prior post, I would make this more
generic - i.e., not named "level" -  and deal with valid values, meaning,
and format, in a per-method description in the documentation)
--compress-location

Users have different preferences for what they want to use, and it provides
a level of self-documentation for the composite specification and a degree
of explicitness for the actual documentation of the methods.

One missing feature in this spec is the ability to specify compression
> to be used with whatever the default method is.  I'm not sure we want to
> allow for that
>

I'm not too keen on making a default method in code.  Saying "if in doubt
gzip is a widely used compression method." in the documentation seems
sufficient.

David J.