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
> 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.
>
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.
> 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.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
