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