Re: Permanent settings

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> All this discussion seems to me to be going off into the clouds, where
>> every objection is met with some still more elaborate scheme. I think we
>> need to look at simple, incremental, and if possible backwards
>> compatible changes.
>
> +1. Let me propose the simplest possible scheme, namely
>
> The SQL-exposed function knows how to find and replace the definition
> of a variable (commented or otherwise) in the primary configuration
> file. It does not chase INCLUDEs. If it doesn't find the target
> variable anyplace in the primary file, it errors out.

I think there are a few problems with having the function edit the primary
config file:

1) It requires parsing and dealing with arbitrary user data. There could be
comments on the same line, the order or white-space might be important to the
user, etc.

2) How would this interact with config files outside of the data directory? If
you have multiple postgres clusters using the same config fie or if your
config file is in read-only media (as /etc often is) or if you're a packager
where editing user-maintained /etc files is a forbidden and an awful idea this
all leads to problems.

I think it's much cleaner to have a postgresql.conf.auto file in the data
directory which has a limited syntax. No comments, no extra white-space, and
no includes. The user is not expected to edit it, though he can. The functions
edit it using simple algorithms which add and remove single lines.

The default config file then includes this postgresql.conf.auto and the
sysadmin can decide whether to keep or remove that include, change
configuration options before or after the include, etc.

Actually this is very similar to how a lot of other packages manage their
automatically maintained data. Apache used to be done like this on Debian (now
it's a bit more complex using a directory, but the same idea). Emacs's
custom.el package can be set up in a similar way where custom.el edits a
separate file which you include from your .emacs.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!