On Mon, Jan 17, 2022 at 8:41 AM Alvaro Herrera <alvhe...@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.