Re: Patch for listing runtime option details through server

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Aizaz Ahmed <aahmed(at)redhat(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, <tgl(at)redhat(dot)com>, Fernando Nasser <fnasser(at)redhat(dot)com>
Subject: Re: Patch for listing runtime option details through server
Date: 2003-07-01 00:09:40
Message-ID: Pine.LNX.4.44.0307010153200.3958-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Aizaz Ahmed writes:

> The attached patch adds the --long-help option to the server executable.

Conceptual comments:

If the option is named --long-help, I'd expect a longer version of
--help, which this is not. The name should probably involve "help"
and "config" to make it clearer what you get. (Personally, I think
"help" should go before the qualifying word, but there may be other
opinions.)

Do we really want to encode the notion of option categories into the
source code? This looks like a pretty large burden to me. Organizing
the documentation or the sample files in user-friendly ways is one
thing, but if I need to organize the code and new options along those
lines, I'm not sure.

If, on the other hand, we like the code to know about categories,
should this code be capable of generating the sample file
automatically?

I don't think we need two different machine formats -m and -M. The
machine isn't going to need the column headers anyway.

The help message should be printed by --help, not -h. In fact, I
don't think there should be a separate subhelp message. Users know
about --help, and that should give them all information about all
invocation modes right there.

Code comments:

To mark up string literals, where you use translatable(), there is
already a standard function gettext_noop() available.

When inserting lines into an existing help message, please observe the
style conventions (capitalization, punctuation, etc.) of the
surrounding lines.

There is already a file guc.c, why should there be a file pg_guc.c
now? That doesn't make sense; the names should be differentiated
better.

Why have various things been moved from guc.h to guc_vars.h, which
seems to just split things up uselessly?

Why are there long explanations in some cases only? Do you plan to
add others later? I also think the messages should be made more
consistent in various ways, but that can be done later.

Should options not for general use (e.g., session_auth_is_superuser)
be hidden from this tool? Are they? What other provisions of this
kind does this tool make?

The GucContext_names are not translatable. They aren't English words
either.

--
Peter Eisentraut peter_e(at)gmx(dot)net

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2003-07-01 00:10:21 Re: svedish trans
Previous Message Peter Eisentraut 2003-07-01 00:09:04 Re: Postgresql.conf, initdb patch