Re: Order getopt arguments - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Order getopt arguments
Date
Msg-id CA+TgmoY7xALWJnTW0PR4620q468+qeVcw3_UQ9_MV=EKMS2-Kw@mail.gmail.com
Whole thread Raw
In response to Re: Order getopt arguments  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Order getopt arguments  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 5, 2022 at 3:42 AM Fabien COELHO <coelho@cri.ensmp.fr> wrote:
> > I had noticed that most getopt() or getopt_long() calls had their letter
> > lists in pretty crazy orders.  There might have been occasional attempts
> > at grouping, but those then haven't been maintained as new options were
> > added. To restore some sanity to this, I went through and ordered them
> > alphabetically.
>
> I agree that a more or less random historical order does not make much
> sense.
>
> For pgbench, ISTM that sorting per functionality then alphabetical would
> be better than pure alphabetical because it has 2 modes. Such sections
> might be (1) general (2) connection (3) common/shared (4) initialization
> and (5) benchmarking, we some comments on each.

I don't see the value in this. Grouping related options often makes
sense, but it seems more confusing than helpful in the case of a
getopt string.

+1 for Peter's proposal to just alphabetize. That's easy to maintain,
at least in theory.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump: Remove "blob" terminology
Next
From: Tom Lane
Date:
Subject: Re: Error-safe user functions