Re: Patch for listing runtime option details through server

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Patch for listing runtime option details through server
Дата
Msg-id Pine.LNX.4.44.0307010153200.3958-100000@peter.localdomain
обсуждение исходный текст
Ответ на Patch for listing runtime option details through server executable (pg_guc)  (Aizaz Ahmed <aahmed@redhat.com>)
Ответы Re: Patch for listing runtime option details through server executable (pg_guc)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@gmx.net


В списке pgsql-patches по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Postgresql.conf, initdb patch
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: svedish trans