Re: change name of redirect_stderr?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: change name of redirect_stderr?
Дата
Msg-id 10620.1187119571@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: change name of redirect_stderr?  (Michael Glaesemann <grzm@seespotcode.net>)
Ответы Re: change name of redirect_stderr?
Список pgsql-hackers
Michael Glaesemann <grzm@seespotcode.net> writes:
> AIUI, if the-GUC-yet-to-be-named is not enabled, no logging is done  
> at all: messages are just sent to stderr. Why something simple like  
> enable_logging or start_logger?

Um, that's still logging by my definition.  I could live with
"start_logger", since that is not the same as "logging".

It could be that if we want real consistency we're going to have to make
more changes than this one.  Consider something like this:

* All variables that cause a specific kind of log message to be printed
or not shall be named "log_<something>".  (So "log_" is a verb.)

* Variables that affect the logging mechanism as a whole shall be named
"logging_<something>".

For example, "log_line_prefix" is misnamed under this rule, and ought to
be "logging_line_prefix".  Similarly, redirect_stderr would become
"logging_something" --- I'd prefer "logging_start_collector" but could
live with "logging_collector" (or maybe "logging_use_collector"?)

Looking at the docs, there are a whole bunch of GUCs that would have
to be renamed to meet this rule, but I think it would become clearer
what does what.

Is that too radical?
        regards, tom lane


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: tsearch2 in PostgreSQL 8.3?
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: tsearch2 in PostgreSQL 8.3?