Re: pg_basebackup --xlog compatibility break
От | Magnus Hagander |
---|---|
Тема | Re: pg_basebackup --xlog compatibility break |
Дата | |
Msg-id | CABUevEwxvy+mQjDPrM2CG=d4=9xNCLkKufd=RziCGcFLniUOWQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_basebackup --xlog compatibility break (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: pg_basebackup --xlog compatibility break
|
Список | pgsql-hackers |
On Tue, May 29, 2012 at 8:51 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, May 30, 2012 at 2:03 AM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Mon, May 28, 2012 at 4:38 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> On Mon, May 28, 2012 at 10:11 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >>>> In 9.1, the pg_basebackup option --xlog takes no argument. In 9.2, it >>>> takes a required argument. I think such compatibility breaks should be >>>> avoided, especially in client-side programs. Now you can't write a >>>> script running pg_basebackup that works with 9.1 and 9.2, if you need to >>>> include the WAL. >>>> >>>> I think the behavior of -x/--xlog should be restored to the state of >>>> 9.1, and a new option should be added to select between the fetch and >>>> stream methods. (With a suitable default, this would also increase >>>> usability a bit.) >>> >>> Just to be clear - it's not possible to actually accept -x with an >>> *optional* parameter, is it? Meaning "-x" would mean the same as "-x >>> fetch" and therefor become backwards compatible? >>> >>> IIRC I did try that, and didn't get it to work - but if that's doable, >>> that seems like the cleanest way? >> >> Aren't you still going to have situations where it's the behavior >> changes, if you go this route? >> >> Consider this command line: >> >> $ foo -b bar >> >> Is bar an argument to -b, or an argument to foo? If -b required or >> forbade an argument it would be clear, but if the argument is optional >> then it's fuzzy. Similarly, consider: >> >> $ foo -bar >> >> If -b takes no argument then this means the same thing as "foo -b -a >> -r", but and if -b requires an argument then ar is the argument to >> foo. If -b takes an optional argument, then it's ambiguous. >> >> I don't remember the exact behavior of getopt_long(), but I bet if we >> go this route we'll find that there are cases where the behavior >> changes vs. older releases; they'll just be subtler. Peter's >> suggestion of a separate switch seems better to me for that reason. > > You're right. I thought that optional parameter is possible because > I recalled GNU extended getopt(3) supported that. After reading its man, > I found that an argument must be in the same word as the option name > to specify an argument, e.g., -xfetch (not -x fetch). This optional > parameter looks confusing to a user. So I agree to add another parameter. Yeah, good arguments all around, i agree too :-) Next question is - suggestions for naming of said paramter? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
В списке pgsql-hackers по дате отправления: