Re: Permanent settings - Mailing list pgsql-hackers

On Tue, Feb 19, 2008 at 11:27:47PM -0500, Robert Treat wrote:
> On Tuesday 19 February 2008 20:08, Tom Lane wrote:
> > Josh Berkus <josh@agliodbs.com> writes:
> > > On Tuesday 19 February 2008 15:05, Bruce Momjian wrote:
> > >> One idea would be to remove duplicate postgresql.conf appended entries
> > >> on server start.
> > >
> > > I think anything which has us appending extra settings to the end of the
> > > file is a non-starter.  We'd get "I changed the setting, but nothing's
> > > happening" error reports 8x hour on #postgresql.
> >
> > Yeah, I agree.  Any proposal that makes it materially harder for people
> > to maintain the config files with an editor is going to suffer so much
> > push-back that it will ultimately fail.  And adding extra copies of
> > settings to an existing file does make it harder.
> >
> 
> +1

That is indeed what I'd prefer, but the other way would "have less impact"
on those that prefer config files. As in they could easily get rid of it.


> > What I would suggest is to write a function in contrib/adminpack that
> > updates the config file by replacing the variable assignment in-place.
> > (Yes, it will have to be smart enough to parse the config file, but
> > that hardly requires a great deal of smarts.)  If that implementation
> > sees sufficient usage then we can migrate the functionality into core.

Wel,l it would take some logic to deal with:
log_destination = 'stderr'    # This is where we're sending the log

But more to deal wtih
#
# This is a long comment about why we moved to syslog because of
# blah blah blah blah lah
#
log_destination = 'syslog'   # Yeah, we really did go to syslog!


Now, if you change log_destination, you really should change both the
comments as well. An easy way would be to just say "don't use combinations
of the two ways" and have the user deal with it, though.


> phppgadmin would certainly use said function if it existed in core, so I'd 
> suggest if we go that route put it in 8.4 straight away.  My guess is it 
> would also be easier to maintain if it was built-in. 

As I said before, my goal is to get rid of the adminpack and merge the
functionality into core. Let's not add new stuff there. 

I've seen several cases of people choosing the windows version over the
unix one simply because the functionality provided by the adminpack is not
available on Unix by default. Sure, a little research would show it's
fairly easy to get it in there, but nevertheless it's *seen* as a
deficiency.


> > It was complained up-thread that some installations make the config
> > files read-only to the postgres user, but I see no conflict there.
> > Anyone who does that is saying that they don't *want* automatic changes
> > to the configuration settings.  Such folk will not consider it a
> > feature for the database to make an end-run around that policy.
> >
> 
> Hmm.... I don't think I've ever seen one like this, but thinking about it I 
> suppose I could see the argument and way to do it... but yes, I think you'd 
> get an error that the file was read-only, so the behavior would be similar to 
> trying to edit it on the box as postgres user. 

Right, I don't see any problem at all with this. The default as set by
initdb is that you can edit it. If you want to lock it down by permissions,
go right ahead, but don't expect the GUIs for configuration to work after
that. Seems very straightforward.

//Magnus