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