Re: RFC: programmable file format for postgresql.conf

On 06/12/2013 19:11, David Johnston wrote:
> Álvaro Hernández Tortosa wrote
>>> Note that you are not required to maintain your configuration data in a
>>> postgresql.conf-formatted file. You can keep it anywhere you like, GUI
>>> around in it, and convert it back to the required format. Most of the
>> I think it is not a very good idea to encourage GUI tools or tools to
>> auto-configure postgres to use a separate configuration file and then
>> convert it to postgresql.conf. That introduces a duplicity with evil
>> problems if either source of data is modified out-of-the-expected-way.
>>
>> That's why I'm suggesting a config file that is, at the same time,
>> usable by both postgres and other external tools. That also enables
>> other features such as editing the config file persistently through a
>> SQL session.
> For my money I'd rather have a single file and/or directory-structure where
> raw configuration settings are saved in the current 'key = value' format
> with simple comments allowed and ignored by PostgreSQL. And being simple
> key-value the risk of "out-of-the-expected-way" changes would be minimal.

What I meant by "out-of-the-expected-way" is that if you edit
postgresql.conf directly rather than through a tool (assuming you're
regularly using the tool), then those changes may get lost when you use
the tool again. In other words, there's potentially "duplicated
information", and we all know that it's not desirable.
> If we want to put a separate "configuration meta-data" file out there to
> basically provide a database from which third-party tools can pull out this
> information then great. I would not incorporate that same information into
> the main PostgreSQL configuration file/directory-structure. The biggest
> advantage is that the meta-data database can be readily modified without any
> concern regarding such changes impacting running systems upon update. Then,
> tools simply need to import "two" files instead of one, link together the
> meta-data key with the configuration key, and do whatever they were going to
> do anyway.
Despite I think it's not ideal to have two separate, both editable,
files for configuring postgresql, if:

- Both would be included in the official distribution, one alongside the
other one
- A tool for converting the new one into the current postgresql.conf is
included also with the distribution, say bin/pgconfiguration or whatever

then I'd agree that it could be a great first step to both adding
support for external tooling for configuring postgres, and providing new
users with a lot more help if they don't use any other tool.

Of course, other tools could be completely external to the
postgresql distribution, but not the "alternate" configuration file and
the pgconfiguration program.

Would this be a good thing to do then?

> If indeed that target audience is going to be novices then a static
> text-based document is not going to be the most desirable interface to
> present. At worse we should simply include a comment-link at the top of the
> document to a web-page where an interactive tool for configuration file
> creation would exist. That tool, at the end of the process, could provide
> the user with text to copy-paste/save into a specified area on the server so
> the customizations made would override the installed defaults.

I think both could be used a lot, editing directly a rich
configuration file or using a GUI tool. I'm trying to suggest supporting
both.

Regards,

aht