> > Magnus Hagander wrote:
> >> The patch mimcs the syslog handling in most cases. It also hijacks
> >> the syslog guc variable.
>
> > I'm less happy about this. In fact the 0 | 1 | 2 for syslog is very
> > hokey anyway. What is more, it is not inconceivable that
> someone would
> > run syslogd on a Windows host, especially if it pointed to a remote
> > syslog. Such things exist, as a quick Google search will
> demonstrate.
> > (I'm not sure if we have any API available on WIndows to
> support it, but
> > that's another question.)
>
> > I would rather see the setting cleaned up and allow zero or more of
> > stdout, syslog, and eventlog (and it should probably be called
> > log_destination or some such instead of syslog).
>
> Agreed. I recall dumping on someone just recently because
> they proposed a new GUC variable with a similarly
> unreadable-except-to-bit-pushers definition. We should take
> the opportunity to install a more user-friendly definition.
>
> As with the other stuff we've been talking about, I see no
> serious backwards-compatibility concern for this particular
> variable, since it's only likely to get touched in the
> postgresql.conf file.
Ok. I will updated this patch to include the replacing of the "syslog"
variable with another one that is more flexible.
Based on what Andrew wrote, configuration along the line of:
log_destination stdout
(for default)
log_destination stdout,syslog
(for syslog=2)
log_destination eventlog
(for win32 eventlog only)
etc etc.
Is that what you were thinking of?
//Magnus
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
