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
signature.asc
Description: PGP signature
