On Mon, 19 Feb 2007, Alvaro Herrera wrote:
> We already have a "combined GUC option" that is used to change two
> different things (DateStyle) and I regularly see people confused about
> how to use it.
You already have a combined GUC option called log_destination that's
sitting in the appropriate area of the configuration file, doing something
similar to what's needed for the new feature. People confused by that are
already confused.
> Also, "sql" is not really a destination -- it is a format.
A log file with a different name is another destination. eventlog is
certainly a different format and it's sitting happily as an option there.
I haven't heard anyone make a useful argument yet as to how insert/sql
logs are any different than the current way that stderr, syslog, and
eventlog are all possibilities now for log_destination, each with their
own little quirks (and in the case of syslog, their own additional GUC
parameters).
> That way you can choose to have one or the other, or both if you're
> really dumb.
The fact that you're characterizing people who might want both as "really
dumb" tells me you're not familiar with enterprise logging requirements. I
already commented on situations where wanting both types of output going
at once is going to absolutely be a requirement in some environments for
this feature addition to be useful; there are a lot of large operations
that rely heavily on features like syslog to help manage their systems.
Most of the places I've worked at, the syslog server where the analysis is
running wasn't necessarily even in the same state as the machine
generating the log entries.
I know I can't deploy this feature unless it operates in parallel with the
existing text-based info going to syslog, both because of that and because
of transition issues--I can't disrupt the existing logs to test a new log
mechanism until that new mechanism has proven itself. I'll probably
deploy it with both turned on forever once it's available.
As for your comments on syslog vs. stderr, I completely agree with
Guillaume's response to you on that subject. The stderr output is
difficult to use for the reasons he describes, but the kind of
environments that use complicated logging aren't relying on that anyway.
I wouldn't get distracted by fixing that implementation when it's
functional enough for most who are satisfied with stderr output.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD