Re: pg_upgrade: Make testing different transfer modes easier

At Thu, 1 Dec 2022 16:18:21 +0100, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote in
> I wanted to test the different pg_upgrade transfer modes (--link,
> --clone), but that was not that easy, because there is more than one
> place in the test script you have to find and manually change. So I
> wrote a little patch to make that easier. It's still manual, but it's
> a start. (In principle, we could automatically run the tests with
> each supported mode in a loop, but that would be very slow.)
>
> While doing that, I also found it strange that the default transfer
> mode (referred to as "copy" internally) did not have any external
> representation, so it is awkward to refer to it in text, and obscure
> to see where it is used for example in those test scripts. So I added
> an option --copy, which effectively does nothing, but it's not
> uncommon to have options that select default behaviors explicitly. (I

I don't have a clear idea of wheter it is common or not, but I suppose many such commands allow to choose the default behavior by a configuration file or an environment variable, etc. But I don't mind the command had the effetively nop option only for completeness.

> also thought about something like a "mode" option with an argument,
> but given that we already have --link and --clone, this seemed the
> most sensible.)
>
> Thoughts?

When I read up to the point of the --copy option, what came to my mind
was the --mode=<blah> option. IMHO, if I was going to add an option
to choose the copy behavior, I would add --mode option instead, like
pg_ctl does, as it implicitly signals that the suboptions are mutually
exclusive.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center