Re: RFC: programmable file format for postgresql.conf

On 13/12/13 04:11, Greg Stark wrote:
>
> On 12 Dec 2013 04:20, "Álvaro Hernández Tortosa" <aht(at)nosys(dot)es
> <mailto:aht(at)nosys(dot)es>> wrote:
>
> > Thanks, Greg. I've been going through those threads, they are
> quite interesting. I didn't find an answer, though, about my question:
> why parsing the postgresql.conf (and for instance preserving the
> comments while writing it back) is no longer a problem
>
> Parsing it isn't hard. It's precisely because the file isn't
> programmable and is such a simple format that's easy to parse.
>
> It's making changes and then writing it out again while preserving the
> intended format that's hard.

Sure, it's writing back the "difficult" part.
>
> So we convinced people to stop trying to do that.
>
> The whole idea of include rules is to separate the portion of the file
> that's human edited and the portion that's machine maintained. That's
> the only viable strategy.

I agree that makes the file "programmable" (in a limited way). You say
you're trying to stop people trying to do that, but that's precisely
what is needed to, for example, create tools to help configure postgres!

Going back to my original email, the main issues I wanted to analyze
were basically:

- Adding metainformation to the config file so that non-expert users
(i.e., the great and vast majority of postgres users) can configure
postgresql more easily (by having extra information in-place, such as
the min val, max val, vartype, comments and URL to the docs).

- Adding metainformation to the config file so that this metainformation
is centrally located and self-contained. This in turn encourages tool
devs to create both GUI tools for configuring postgres and automatic
tools. I consider "critical" the "centrally located" part, as it becomes
a "framework" or "repository" of metainformation, so that tool devs
don't have to write their own for every tool.

I now realize that maybe I should have called my post "Adding
metainformation to the postgresql.conf file" or something like that.

The include mechanism allows some degree of programmability, but it has
to be in a format compatible with the current postgresql.conf file that
doesn't contain this metainformation.

To achieve the goals above, I think the only viable way would be to
ship with the postgresql distribution a file with all the
metainformation, which could:

- either be the postgresql.conf file itself (which would need a
different format, of course)

- or an external file with an included program to convert that file to
the current postgresql.conf

Please let me know if there would be a third or fourth option.

I started some little research on the second approach, and I'll post
back with a file format and code of a proof of concept tool to convert
to postgresql.conf and help users configure postgresql both from a GUI
and CLI.

Regards,

aht

--
Álvaro Hernández Tortosa

-----------
NOSYS
Networked Open SYStems