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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, noah(at)leadboat(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: add non-option reordering to in-tree getopt_long
Date: 2023-07-13 05:39:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 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")

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Pyhalov 2023-07-13 06:49:42 Re: CREATE INDEX CONCURRENTLY on partitioned index
Previous Message Michael Paquier 2023-07-13 05:26:42 Re: 'ERROR: attempted to update invisible tuple' from 'ALTER INDEX ... ATTACH PARTITION' on parent index