Re: Permanent settings
От | Aidan Van Dyk |
---|---|
Тема | Re: Permanent settings |
Дата | |
Msg-id | 20080219145330.GF10774@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Permanent settings (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Permanent settings
|
Список | pgsql-hackers |
* Magnus Hagander <magnus@hagander.net> [080219 09:37]: > One way might be to simply have the config file reader store the location > for each setting where it was found, and when you do a SET PERMANENT (if > that's what we'd call it) it'll go back to that place and make the > modification there. If a setting hasn't previously been set, we could just > append it to the end of the main configuration file. > > One thing that can be hard to deal with is comments. It would be good if > there was some way to support reading/writing simple comments (say a # at > the end of the line) through this API, but I think it's OK not to deal with > complex multi-line comments. I think it's fairly safe to say that the vast > majority of users will *either* change their configuration through the > config file *or* through the API. Or those that use both aren't likely to > use really complex combinations of config files and comments and such. Speaking as one who favours the unix admin style (i.e. editing the config file), take the following with a grain of salt. But if you *need* a way to "set permanent", couldn't you do with with the following KISS idea? Any "set permanent" settings should be *appended* to the main config file, preferably with a comment line, like:# Set by user <USER> from client <CLIENT> on <TIMESTAMP>some_guc option = some_value This does 2 things: 1) Eliminates a need for a fancy config parser/editor/rewriter 2) Makes it very easy to implement 3) Even allows adminpack to have a "set_permanent" function that could do it all internally, and not actually need supportin the backend core. This relies on the fact that a "later" setting over-rides an earlier one. This also means that your postgres user actually has write access to the config files (is this something people normally allow?) I guess this "write" problem could be overcome with yet-another-guc to specify the "permanent write file" path.. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: