Re: add non-option reordering to in-tree getopt_long

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Thu, Jul 13, 2023 at 09:38:42PM -0700, Nathan Bossart wrote:
>> Take the following examples of client programs that accept one non-option:
>>
>> ~$ pg_resetwal a b c
>> pg_resetwal: error: too many command-line arguments (first is "b")
>> pg_resetwal: hint: Try "pg_resetwal --help" for more information.
>>
>> Yet pg_ctl gives:
>>
>> ~$ pg_ctl start a b c
>> pg_ctl: too many command-line arguments (first is "start")
>> Try "pg_ctl --help" for more information.
>>
>> In this example, isn't "a" the first extra non-option that should be
>> reported?

> Good point. This is interpreting "first" as being the first option
> that's invalid. Here my first impression was that pg_ctl got that
> right, where "first" refers to the first subcommand that would be
> valid. Objection withdrawn.

We just had a user complaint that seems to trace to exactly this
bogus reporting in pg_ctl [1]. Although I was originally not
very pleased with changing our getopt_long to do switch reordering,
I'm now wondering if we should back-patch these changes as bug
fixes. It's probably not worth the risk, but ...

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/CANzqJaDCagH5wNkPQ42%3DFx3mJPR-YnB3PWFdCAYAVdb9%3DQ%2Bt-A%40mail.gmail.com