On Tue, Oct 27, 2009 at 9:05 PM, Josh Berkus <j...@agliodbs.com> wrote:
>> The Apache model is definitely the first of these, AFAICS.  The
>> proposals on this thread mostly seem to be an amalgam of both, which
>> doesn't strike me as a terribly good idea, but evidently I'm in the
>> minority.
>
> Well, an individual DBA would not want to do it both ways.  But we
> should *allow* both ways rather than trying to mandate how the files get
> created or what their names are.

I guess all I'm saying is that if we took the approach of making SET
PERSISTENT rewrite postgresql.conf, we actually could let people do it
either way they pleased without the complexity of having multiple
files.

The only reason we can't do that today is because postgresql.conf
contains unparseable comments.  The only way to fix that problem
completely is, as Tom says, to remove the ability to have comments.
But that seems like overkill.  If we simply removed most of the
comments that are there by default, then we could say: "You can edit
this file with a text editor.  Or you can edit it using SET
PERSISTENT.  Or you can do both.  But if you do both, your comments
may end up getting moved relative to your settings.  So if you care
about that, then don't use SET PERSISTENT.  In fact, if you want,
there's a GUC called enable_set_persistent that you can set to false."

That seems like a win for everyone.  People who want to use a text
editor can do so.  People who want to use SET PERSISTENT can do so.
People who want to do both can do so, too, and without the confusion
of having two different places for settings one of which will override
the other.  I think the only people who will be unhappy are (1) people
who like the current really long postgresql.conf [but the previous
discussion of this topic suggested there weren't too many of those]
and (2) people who want to edit postgresql.conf by hand AND want to
edit it with SET PERSISTENT AND can't stand having their comments
shuffled around relative to their settings [but these people will
never be happy no matter what we do].

But evidently this is not such a good idea as I think it is, or else
I've been explaining it really, really badly.

...Robert

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to