Re: RFC: programmable file format for postgresql.conf - Mailing list pgsql-hackers

On 13/12/13 04:11, Greg Stark wrote:
>
> On 12 Dec 2013 04:20, "Álvaro Hernández Tortosa" <aht@nosys.es
> <mailto:aht@nosys.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