Re: [HACKERS] Logging - pg_options format change?
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Logging - pg_options format change? |
Дата | |
Msg-id | 199910261624.MAA23357@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Logging - pg_options format change? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Tim Holloway <mtsinc@southeast.net> writes: > > Would it be objectionable if I altered the format of the pg_options > > file slightly? I feel the need to handle a somewhat more complex > > syntax for the logging subsystem. > > While I'm not particularly wedded to the pg_options format, I wonder > whether it wouldn't be a better idea to create a separate file for > the logging control data. If I'm reading your proposal correctly, > the backend would no longer parse existing pg_options files --- and > that's certain to make dbadmins unhappy, even if the fix is easy. > Upgrades are always stressful enough, even without added complications > like forced changes to config files. > > You could probably tweak the syntax so that an existing pg_options > file is still valid, but that might be a bit too klugy. What's > wrong with having two separate files? We can assume that this isn't > a performance-critical path, I think. With a 7.0 release, I think we can revamp that file without too many complaints. pg_options file is fairly new, and it is an administrator's thing, and only has to be done once. Seems like a revamp to make it clear for all users would help. Having two files would mean explaining that to people for ever. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: