Horton

Thread

Commits

  1. Order getopt arguments

  1. Order getopt arguments

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-12-05T08:29:53Z

    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.

  2. Re: Order getopt arguments

    Fabien COELHO <coelho@cri.ensmp.fr> — 2022-12-05T08:42:41Z

    Hello Peter,

> 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.

What do you think? If okay, I'll send you a patch for that.

-- 
Fabien.

  3. Re: Order getopt arguments

    Robert Haas <robertmhaas@gmail.com> — 2022-12-05T15:57:04Z

    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

  4. Re: Order getopt arguments

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-12-05T16:13:39Z

    Robert Haas <robertmhaas@gmail.com> writes:
> +1 for Peter's proposal to just alphabetize. That's easy to maintain,
> at least in theory.

Agreed for single-letter options.  Long options complicate matters:
are we going to order their code stanzas by the actual long name, or
by the character/number returned by getopt?  Or are we going to be
willing to repeatedly renumber the assigned codes to keep those the
same?  I don't think I want to go that far.

			regards, tom lane

  5. Re: Order getopt arguments

    Robert Haas <robertmhaas@gmail.com> — 2022-12-05T16:21:20Z

    On Mon, Dec 5, 2022 at 11:14 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > +1 for Peter's proposal to just alphabetize. That's easy to maintain,
> > at least in theory.
>
> Agreed for single-letter options.  Long options complicate matters:
> are we going to order their code stanzas by the actual long name, or
> by the character/number returned by getopt?  Or are we going to be
> willing to repeatedly renumber the assigned codes to keep those the
> same?  I don't think I want to go that far.

I was only talking about the actual argument to getopt(), not the
order of the code stanzas. I'm not sure what we ought to do about the
latter.

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

  6. Re: Order getopt arguments

    Tom Lane <tgl@sss.pgh.pa.us> — 2022-12-05T16:51:07Z

    Robert Haas <robertmhaas@gmail.com> writes:
> I was only talking about the actual argument to getopt(), not the
> order of the code stanzas. I'm not sure what we ought to do about the
> latter.

100% agreed that the getopt argument should just be alphabetical.
But the bulk of Peter's patch is rearranging switch cases to agree
with that, and if you want to do that then you have to also think
about long options, which are not in the getopt argument.  I'm
not entirely convinced that reordering the switch cases is worth
troubling over.

			regards, tom lane

  7. Re: Order getopt arguments

    Robert Haas <robertmhaas@gmail.com> — 2022-12-05T17:04:38Z

    On Mon, Dec 5, 2022 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I was only talking about the actual argument to getopt(), not the
> > order of the code stanzas. I'm not sure what we ought to do about the
> > latter.
>
> 100% agreed that the getopt argument should just be alphabetical.
> But the bulk of Peter's patch is rearranging switch cases to agree
> with that, and if you want to do that then you have to also think
> about long options, which are not in the getopt argument.  I'm
> not entirely convinced that reordering the switch cases is worth
> troubling over.

I'm not particularly sold on that either, but neither am I
particularly opposed to it.

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

  8. Re: Order getopt arguments

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2022-12-12T14:24:17Z

    On 05.12.22 18:04, Robert Haas wrote:
> On Mon, Dec 5, 2022 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> I was only talking about the actual argument to getopt(), not the
>>> order of the code stanzas. I'm not sure what we ought to do about the
>>> latter.
>>
>> 100% agreed that the getopt argument should just be alphabetical.
>> But the bulk of Peter's patch is rearranging switch cases to agree
>> with that, and if you want to do that then you have to also think
>> about long options, which are not in the getopt argument.  I'm
>> not entirely convinced that reordering the switch cases is worth
>> troubling over.
> 
> I'm not particularly sold on that either, but neither am I
> particularly opposed to it.

I have committed it as posted.