Permanent settings - Mailing list pgsql-hackers

Currently, pgAdmin supports editing postgresql.conf remotely using the
adminpack to open the file, change it locally in memory, and using the
adminpack again to write it back. This means that in theory pgAdmin needs a
full postgresql.conf parser. Right now it doesn't have this - it just
exposes the config file itself. Which sucks for usability, and it's
something I've heard a lot of people complain about. Other databases (in my
personal experience MSSQL, but IIRC I've had people say the same about
other ones as well) support configuring the database remotely (and using a
GUI for the most common options), and this is a feature that a lot of users
are lacking in PostgreSQL. I'd like to do something about that.


What I'd really like to see is something like a new keyword on the SET
command, so you could to SET PERMANENT foo=bar, which would write the
configuration back into postgresql.conf.

I don't have a complete solution for how to actually implement it, so I'm
just throwing out some ideas for comment.

I don't think we need to be able to parse and deal with "very complex
configuration files", as long as we're not likely to corrupt them badly.

The task got a bit harder with the support of include files, but I'm sure
it's doable.

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.

(before someone complains about the "argh, editing config files remote is
insecure" - we can always have a config option to turn it off. And it can
still be protected by not giving the server write permissions on the file,
or selinux, or whatever)

Thoughts? More ranting?

//Magnus