From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | josh(at)agliodbs(dot)com |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Permanent settings |
Date: | 2008-02-20 01:08:29 |
Message-ID: | 25779.1203469709@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)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.
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Marc G. Fournier | 2008-02-20 01:30:30 | testing a post directly on server |
Previous Message | Tom Lane | 2008-02-20 00:52:38 | Re: Including PL/PgSQL by default |