Re: Parsing config files in a directory

On Sat, Oct 24, 2009 at 9:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't believe that the *ability* to have comments is the problem.
>> It wouldn't hurt anything to ship a file with a general comment block
>> at the top, with whatever content someone wants to put there.  What
>> makes it impossible to machine-edit this file is that there is a
>> comment for every single setting, and that the "right place" to insert
>> a value for any particular setting is (at least in the default
>> configuration) marked by a comment which can be interpreted by humans
>> and not by a computer.
>
> Right, but your mistake is in supposing that that statement has
> something to do with the instructions.  What it has to do with is
> a style of usage that the instructions happen to exemplify --- but
> getting rid of the instructions wouldn't make people change their
> usage habits.

I don't really understand this. What usage habits do we need to
change? The problem is that people expect that the setting for some
GUC is going to be near the comment block that describes that GUC. If
the comment blocks describing those GUCs were gone, then that
expectation would be removed.

It's true that someone might take an empty default file and do
something like this:

# ok, so now i'm going to set work_mem to a ridiculous value
work_mem = '1GB'

And they might be surprised if some automated-config-file rewriter
ended up shuffling the setting to some location in the file that was
no longer close to the comment. But most people probably won't add
things like that if they're not already present, and even if they do
there probably won't be that many of them, and they'll get it sorted
out.

> I concur with Greg Smith's nearby comments that the way to go at this
> is a stepwise process.  It is only *after* there is a workable tool
> that is a clear improvement on manual editing that you will have any
> chance of getting people to move away from manual editing, or even
> getting them to entertain any change proposals that make manual editing
> less pleasant.

Well, there are certainly config-tuning tools already. Just since I
started reading this list, there is pgtune; and I'm sure there are
others I don't know about. Coming up with the settings is the easy
part; getting them into the file is the hard part. There have also
been several requests for a SQL command that updates postgresql.conf,
which would not be very hard to write if we made it so that such a
command needn't care about the comments beyond preserving them, but
which is completely unworkable as things stand. I think it's
completely backwards to suppose that nobody has written the tools but
when they do we'll consider adjusting the file; rather, people have
done the best they can already given that the file is very difficult
to work with, and when/if it stops being so difficult, they'll likely
do more.

I realize that the current file format is an old and familiar friend;
it is for me, too. But I think it's standing in the way of progress.
Being able to type a SQL command to update postgresql.conf would be
more substantially convenient than logging in as root, using su to
become postgres, changing to the correct directory, starting up vi,
finding the right setting, editing it, quitting out, and requesting a
reload. And I deal with 1 PostgreSQL instance at a time, not tens or
hundreds or thousands.

...Robert