Order getopt arguments
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.
Attachments:
0001-Order-getopt-arguments.patchtext/plain; charset=UTF-8; name=0001-Order-getopt-arguments.patchDownload+458-465
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.
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
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
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
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
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
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.