Re: Permanent settings

On Wed, Feb 20, 2008 at 01:27:25PM -0500, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)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 :-(

Right, this is one of the reasons for the suggestion to use a separate
include file where the user isn't supposed to be editing it manually at
all.

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

That's what we have now, and it basically forces each frontend to do the
implementatino themselevs. E.g. pgadmin has one implementation, phppgadmin
has another implementation, apparantly Greg has one implementation, there
may be third party ones out there with their own implementation.

The point is we need one implementatino that's in the server, because that
takes away redundancy and it makes it easier to maintain.

//Magnus