Re: Initial eventlog support on win32
От | Magnus Hagander |
---|---|
Тема | Re: Initial eventlog support on win32 |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE34B5A0@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Initial eventlog support on win32 ("Magnus Hagander" <mha@sollentuna.net>) |
Ответы |
Re: Initial eventlog support on win32
Re: Initial eventlog support on win32 |
Список | pgsql-patches |
> > 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
В списке pgsql-patches по дате отправления: