* 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.
