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
