Re: Parsing config files in a directory

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Tue, Oct 27, 2009 at 8:40 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> You're hearing from the people who are working on tools: requiring that
>> any tool parse a hand-written config file is a non-starter.
>
> It can be done, pgadmin actually does it currently. But I totally
> agree it's a bad idea.
>
> But the difficulty of parsing the handwritten stuff is not the only
> reason it's a bad idea. Any time you have multiple pieces of software,
> to say nothing of humans, editing the same file you're going to have
> headaches. They need to agree on everything and be able to handle
> anything any other program generates. Such a file would be a kind of
> API itself.

That's why I'm proposing the following API at file level:
- 1 file per GUC
- file name is {class.}guc_name.conf
- first line only contains value of setting
- rest of the file contains comments

Now any tool can see current value for itself, and change it, keeping
the old one as comment is easy too:
$ myguc=`cat postgresql.conf.d/my_guc.conf`
$ (echo newvalue; echo $myguc) > postgresql.conf.d/my_guc.conf

Furthermore, extensions are required to use a custom class, so they will
need to edit custom_variable_classes then their own files. Any tool
could support editing those files too, it's rather easy until you want
to provide specific wizard kind knowledge to the user.

A dedicated facility to add a new class to custom_variable_classes GUC
could be devised later, but doesn't feel like it's in this patch
playground.

> It's much simpler and more reliable to have each program generate a
> separate file.

On the viewpoint of the program itself only. For the DBA, that soon
becomes a nightmare because the same GUC could come from any number of
tools and the precedence rules, even explicit and as easy as
alphanumeric orderding (which locale already?), make it error prone.

I really want to insist on having only ONE location for settings from
tools (all of them) and one location for manual/local editing.

> time it's generated. It doesn't have to worry about anything else
> parsing or making sense of the file except the database server itself.

But it'll never know if the settings it just generated are superseded by
some other tool's configuration file. With my proposal the SET
PERSISTENT command can easily warn user: as soon as current source for
the GUC is NOT postgresql.conf.d you know you're not affecting anything,
it's been the DBA choice to manually set something else.

It if happens you are the DBA, you can go edit postgresql.conf to
comment out the GUC and enjoy your new tool suite.

Regards,
--
dim