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

From Tom Lane
Subject Re: change name of redirect_stderr?
Date
Msg-id 11546.1187123849@sss.pgh.pa.us
Whole thread Raw
In response to Re: change name of redirect_stderr?  ("Brendan Jurd" <direvus@gmail.com>)
Responses Re: change name of redirect_stderr?  ("Brendan Jurd" <direvus@gmail.com>)
Re: change name of redirect_stderr?  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
"Brendan Jurd" <direvus@gmail.com> writes:
> On 8/15/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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"?)

> The consistent prefix idea sounds good; does "logging_enable" jive
> with your proposal?

I dislike it.  I claim that logging to plain stderr (without the
syslogger process) is still logging.  Logging to syslog (which also
doen't need the syslogger process) is *definitely* logging.  Something
named "logging_enable" would suggest to the normal person that without
it turned on, you'll get *nothing*.

I'm not wedded to "collector" per se, but you really cannot escape the
fact that there is one more concept in here than you wish to admit.
I think that reflecting the existence of a collector process in the GUC
names makes things clearer, not less clear.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: default_text_search_config and expression indexes
Next
From: Alvaro Herrera
Date:
Subject: Re: tsearch2 in PostgreSQL 8.3?