Re: Refactoring of compression options in pg_basebackup
От | Robert Haas |
---|---|
Тема | Re: Refactoring of compression options in pg_basebackup |
Дата | |
Msg-id | CA+TgmoY9pNLM6xSGbhsCKbzzoO5b3NUs1_KoDkFb1tjzjowysA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Refactoring of compression options in pg_basebackup ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Refactoring of compression options in pg_basebackup
|
Список | pgsql-hackers |
On Mon, Jan 17, 2022 at 11:50 AM David G. Johnston <david.g.johnston@gmail.com> wrote: >> 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 Iam having trouble deciding. My personal preference is to add --compression and leave --compress alone and deprecated; butwe 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" rulesand "composite value" rules...) 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. > I'm not too keen on making a default method in code. Saying "if in doubt gzip is a widely used compression method." inthe documentation seems sufficient. Yeah, I agree that a default method doesn't seem necessary. People who want to compress without thinking hard can use -z; others can say what they want. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: