Re: Permanent settings - Mailing list pgsql-hackers

On Tue, Feb 19, 2008 at 09:53:30AM -0500, Aidan Van Dyk wrote:
> * 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

Are you suggesting we keep appending? So if I set the same parameter 100
times, it would show up on 100 rows?


> 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 support in the backend core.

I should warn you that it's on my radar to try to find the compromises
necessary to merge the required functionality away from adminpack and into
core for 8.4. Not sure if I'll manage, but I'm certainly going to try.
Having to install contrib modules to be able to read your logfiles (just
one of several examples) is another thing that most users I've come in
contact with hate.

//Magnus