Re: Parsing config files in a directory

On Mon, Oct 26, 2009 at 4:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I'm not sure whether you're saying that I'm bringing this issue up in
>> the wrong thread, or whether you disagree with the basic suggestion.
>
> The former --- whether we want to trim down the commentary in
> postgresql.conf seems to me to have nothing to do with what's
> being discussed in this thread.  As Greg Smith already stated
> in a couple of ways, the issue here is about being able to support
> **simple** tools that make modifications to system-wide parameter
> settings.  Removing default commentary from postgresql.conf does
> not help that at all.

[ shrug ]

I don't particularly agree; but perhaps we can agree to disagree on
this point. For what it's worth, the thing that originally got me
involved in this thread was the following sentence in Magnus' OP.

"The idea being that something like a tuning tool, or pgadmin, for
example can drop and modify files in this directory instead of
modifying the main config file (which can be very hard to
machine-parse)."

I presume this sentence must refer to the aforementioned commentary,
because what else is there in that file that could be hard to parse?
Or that would be any different in an include-dir file?

> Removing the ability to use comments there
> at all might help, but if you haven't figured out yet that no such
> proposal will fly, I'm not sure how much clearer I can say it.

I agree that that would be a bad design, which is why I did not suggest it.

> The desire to not have a ridiculously high bar for config adjustment
> tools also seems to me to be plenty of reason to reject the various
> odd ideas we have seen like making tools go around and edit files
> other than the one they are chartered to put settings in.

I agree completely.

>> on this thread, you suggested dumping the initdb functions into a
>> mostly-empty persistent.conf file that would be read after
>> postgresql.conf.  If we did that, then we would presumably advise
>> people not to set settings in postgresql.conf because of the
>> possibility that they would be overriden in persistent.conf, which
>> begs the question of why we need two files at all.
>
> You are confusing who is in charge here.  It's not the tool, it's
> the DBA, and anybody who thinks differently is going to keep losing
> arguments.  I would actually suggest that it'd be better to put
> the include of persistent.conf first, with a comment (!) pointing
> out that any subsequent manual settings will override that.  Some
> people will choose to use persistent.conf, some won't care to; and
> the main problem I'm seeing in this debate is the apparent desire
> to force the latter group to do what somebody else thinks is good
> for them.  If you design a setup that can be used in multiple styles,
> including the old one, you'll have a lot better chance of getting it
> through.

What you're proposing here will work with both styles, but it might
sometimes exhibit the rather surprising behavior that SET PERSISTENT
appears to work but doesn't actually do anything, with no clear
warning to the user of what has gone wrong. It seems like it would be
better to have some kind of a hard switch - e.g. if
postgresql.conf.auto exists, then we read settings that file, and SET
PERSISTENT updates it. If not, then we read the regular
postgresql.conf file, and any attempt to SET PERSISTENT fails with a
suitably informative error message.

...Robert