Josh Berkus <josh@agliodbs.com> writes:
> 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:
> [snip]
Yeah, those are good examples. It would be fairly easy to deal with a
postgresql.conf file that's in a pristine state, but I can see that
distinguishing "commented-out values" from actual comments is likely
to be AI-complete :-(
> 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.
I'm starting to wonder why any of this proposal is a good idea at all.
We already have sufficient support for someone to suck out the
postgresql.conf file, edit it remotely, and put it back, so the argument
that this will enable remote administration that you can't do now is
entirely bogus. I don't see what it will buy us that is worth the
problems it will create.
For the point-and-drool crowd that can't cope with editing a text file,
perhaps the best avenue to having a GUI is to build it atop the
just-mentioned facility, namely
1. suck out the current settings.
2. provide a GUI that manipulates the values.
3. write back an entirely new postgresql.conf that doesn't take any
trouble to preserve what was there before.
regards, tom lane