> > 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?


---------------------------(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

Reply via email to