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

On Wed, Jul 12, 2023 at 08:49:03PM -0700, Nathan Bossart wrote:
> After a couple more small edits, I've committed this. I looked through all
> uses of getopt_long() in PostgreSQL earlier today, and of the programs that
> accepted non-options, most accepted only one, some others accepted 2-3, and
> ecpg and pg_regress accepted any number. Given this analysis, I'm not too
> worried about the O(n^2) behavior that the patch introduces. You'd likely
> need to provide an enormous number of non-options for it to be noticeable,
> and I'm dubious such use-cases exist.
>
> During my analysis, I noticed that pg_ctl contains a workaround for the
> lack of argument reordering. I think this can now be removed. Patch
> attached.

Interesting piece of history that you have found here, coming from
f3d6d94 back in 2004. The old pg_ctl.sh before that did not need any
of that. It looks sensible to do something about that.

Something does not seem to be right seen from here, a CI run with
Windows 2019 fails when using pg_ctl at the beginning of most of the
tests, like:
[04:56:07.404] ------------------------------------- 8< -------------------------------------
[04:56:07.404] stderr:
[04:56:07.404] pg_ctl: too many command-line arguments (first is "-D")
--
Michael