Re: change name of redirect_stderr? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: change name of redirect_stderr?
Date
Msg-id 10620.1187119571@sss.pgh.pa.us
Whole thread Raw
In response to Re: change name of redirect_stderr?  (Michael Glaesemann <grzm@seespotcode.net>)
Responses Re: change name of redirect_stderr?  ("Brendan Jurd" <direvus@gmail.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: tsearch2 in PostgreSQL 8.3?
Next
From: Heikki Linnakangas
Date:
Subject: Re: tsearch2 in PostgreSQL 8.3?