Re: Permanent settings

Tom,

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

Hmmm. I guess I'm just not good enough with conf file parsing.

The problem I've constantly run into with parsing and modifying settings
in a user-edited postgresql.conf file is that sometimes users do their
own chronological documentation:

#work_mem = 1mb #original setting
#work_mem = 4mb #2008-01-05 not high enough
#work_mem = 32mb #2008-01-11 too high, OOM killer
work_mem = 16mb #current setting

If the user then chooses to use the API to update work_mem to 12mb, how
do we process the file? Does it become this?

work_mem = 12mb
work_mem = 12mb
work_mem = 12mb
work_mem = 12mb

The above wouldn't seem such a problem, except that sometimes those
individual setting lines could be widely separated in the file,
depending the application's history of DBAs.

Further, sometimes comments can look like this:

# warning! never, ever, ever, set
# work_mem to be more than 16mb, it will
# cause OOM!

Which then gets transformed to:

# warning! never, ever, ever, set
work_mem = 12mb
# cause OOM!

Obviously, these individual cases can be worked around, but as long as
we're trying to preserve our historical human-readable-and-documented
.conf format *and* allow DBAs to hand-edit and machine-edit the same
file, I think we're going to end up writing more "corner case" code than
core implementation. I think an include approach would be a lot cleaner
and less prone to issues.

--Josh