Re: Should we put command options in alphabetical order in the doc?

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Should we put command options in alphabetical order in the doc?
Date: 2023-04-19 18:38:48
Message-ID: CAH2-Wzn8S8aP03Hez+9aaDskKmSbXTOauSo318VZY4KFF6Bktg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 19, 2023 at 3:04 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> > While I'm certain that nobody will agree with me on every little
> > detail, I have to imagine that most would find my preferred ordering
> > quite understandable and unsurprising, at a high level -- this is not
> > a hopelessly idiosyncratic ranking, that could just as easily have
> > been generated by a PRNG. People may not easily agree that "apples are
> > more important than oranges, or vice-versa", but what does it matter?
> > I've really only put each option into buckets of items with *roughly*
> > the same importance. All of the details beyond that don't matter to
> > me, at all.
>
> I agree with you that roughly bucketing items is a good approach.
> Within each bucket we can then sort alphabetically.

I think of these buckets as working at a logarithmic scale. The FULL,
FREEZE, VERBOSE, and ANALYZE options are multiple orders of magnitude
more important than most of the other options, and maybe one order of
magnitude more important than the PARALLEL, TRUNCATE, and
INDEX_CLEANUP options. With differences that big, you have a structure
that generalizes across all users quite well. This doesn't seem
particularly subjective.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-04-19 18:50:51 ExecAggTransReparent is underdocumented and badly named
Previous Message Andres Freund 2023-04-19 17:43:14 Re: Direct I/O