Re: syslog_line_prefix

On Tue, Sep 15, 2009 at 2:18 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Magnus Hagander wrote:
>
>> I'm not sure I like this as a GUC. We're going to end up with a lot of
>> different GUCs, and everytime we add a new log destination (admittedly
>> not often, of course), that increases even further. And GUCs really
>> don't provide the level of flexibility you'd really like to have. I've
>> been thinking (long-term) in the direction of a separate config file,
>> since that could contain an arbitrary number of lines, with "rules" on
>> them (somewhat like pg_hba.conf maybe).
>
> I tend to agree with this idea, but I'm not sure about rejecting the
> current patch because of it.

I'm picking up this patch to review for this CommitFest. I agree that
the idea of this patch is good. It's pretty silly for us to give
people advice that they should not log time stamps and pids to syslog,
but then provide them no way of actually implementing that behavior
when logging to multiple destinations.

On the other hand, I don't think this is the right way to do it. The
patch proposes the following mapping of logging destinations to GUCs:

stderr -> log_line_prefix (same as now)
csvlog -> not applicable (same as now)
syslog -> syslog_line_prefix
eventlog -> syslog_line_prefix

That's not exactly mnemonic; I think we'd want
{stderr,syslog,eventlog}_log_line_prefix if anything. But that seems
like too many GUCs already - for anyone logging to a single
destination (which I would think by far the most common case), it's
just extra work. So I'm inclined to say that we should reject this
patch for now and see what other ideas come down the pipe.

...Robert