Re: Parsing config files in a directory

On Sat, Oct 24, 2009 at 7:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Supporting an include-directory seems harmless to me, and even
>> potentially useful.  But the only way to solve the problem of
>> machine-parsing the config file is to remove the instructions (which
>> can only EVER be parsed by human beings) and put them somewhere else.
>
> Uh, that is complete nonsense.  The instructions are not a problem.
> The ability to have comments at all might be thought to be a problem,
> but removing it isn't going to be an acceptable solution.

If you're saying that the instructions are no more of a problem than
any other comment, then I guess I agree. But the comments in the
default file which we ship are mostly instructions, hence my original
statement.

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.

Shipping a mostly-empty file with a pointer to a man page that
included all of the instructions now contained in the file would make
things immensely easier for people who want to write programs to tune
the configuration, because it would transform the task of writing a
program that rewrites the configuration file from Turing-complete to
very easy. For the same reason, it would also allow us to support SET
PERSISTENT. On the flip side, as long as we leave it the way it is,
we can't do those things. We can argue about whether that's a good
trade-off, but that IS the trade-off.

...Robert