Re: alphabetize long options in pg_dump[all] docs

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql(at)j-davis(dot)com
Subject: Re: alphabetize long options in pg_dump[all] docs
Date: 2025-04-30 11:58:19
Message-ID: 6c015f1a-abe9-4eb6-ac47-cbd3e1a11061@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.04.25 23:54, Nathan Bossart wrote:
> On Tue, Apr 29, 2025 at 11:45:11PM +0200, Álvaro Herrera wrote:
>> I think the concept here is that all short options go first in
>> alphabetical order, then the long options in their own alphabetical
>> order, and if one option has both, then the short option takes
>> precedence.
>
> That's what it looks like to me, too.
>
>> If that's the idea, then --filter in pg_dumpall is in the
>> wrong place, and other than that it looks good.
>
> I missed that one, thanks.
>
>> I think that's what gives the shorter patch. But where would you look
>> for, say, --large-objects? I mean, how do you know that its short
>> version is -b? Maybe it would make more sense to sort on long options
>> first and put short options as the second-priority item for each option.
>
> Fair point. We seem to be pivoting towards long options, anyway. If
> there's support for this, I could go through all the client and server
> application docs to ensure they match this style.

There are two styles currently in use: First, as described above, list
all short options first, then all long-only options. The second style
is that long-only options are listed alphabetically between short
options. I think both of these styles are used in --help output and man
pages, and I've long had a desire to unify under one style. Which would
also be helpful to offer guidance when new options are added.

However, I think this would require coordination across all --help
output and man pages (76 objects), so for the short term, let's just
move recently added options to the right place under the current
theory/theories, and leave a larger reshuffling for later.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-04-30 12:11:32 Re: Add an option to skip loading missing publication to avoid logical replication failure
Previous Message Ajin Cherian 2025-04-30 11:25:23 Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding