On Tue, Sep 15, 2009 at 2:18 PM, Alvaro Herrera <alvhe...@commandprompt.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers