Re: Permanent settings

From: Aidan Van Dyk <aidan(at)highrise(dot)ca>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Permanent settings
Date: 2008-02-19 14:53:30
Message-ID: 20080219145330.GF10774@yugib.highrise.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Magnus Hagander <magnus(at)hagander(dot)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 support in 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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sam Mason 2008-02-19 15:05:47 Re: Common Sub-expression removal
Previous Message Magnus Hagander 2008-02-19 14:36:26 Permanent settings