Re: RFC: programmable file format for postgresql.conf

Hi Peter, Dimitri, thank you for your comments.

On 03/12/13 22:27, Dimitri Fontaine wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On 12/1/13, 2:24 PM, Álvaro Hernández Tortosa wrote:
>>> IMHO, defining a new syntax for the postgreql.conf file format,
>>> that is suitable for writing and parsing, or using an already existing,
>>> well-known, programmatic syntax, could offer a solution for all the
>>> problems/limitations above.
>>
>> That's the problem, there isn't one, is there? The closest you'd get is
>> the INI syntax, but that's like CSV, with many variations. And most
>> client libraries for this will likely drop all comments when they read
>> and write a file, so this doesn't address that issue.

Certainly INI files won't preserve the comments, nor they help adding
extra information to the config file to help users configure postgres
and tools to generate GUIs and/or automatic configuration.

>
> I've been using INI alot in pgloader previously, and I can't tell you
> how happy I am to be away from it now.
>
> I would argue that plenty of programmatic syntax and well known options
> do exist for a configuration format. From Emacs Lisp and Guile to
> Python, including Lua. You will tell me that it's too programmatic for
> what you think is a configuration file, I would argue that it's the best
> choice Emacs (and many other pieces of software) made.
>
> Also if the programmatic part of the idea looks fine to someone who
> never used the lisp syntax, just realise that there's nothing simpler to
> parse nor “better known” (after all, it's been in wild use already for
> more than 50 years).

I agree that there are many options out there, like the ones you
mentioned. I'm unsure if Lisp would be the best one, specially in terms
of newbie-friendness and general "convenience" to replace the current
postgresql.conf, but it should definitely provide with all the
requirements I was suggesting.

IMHO, the key here would be defining first *what* data should this
config file be storing. The idea is that everything that has ever been
thought of as a comment would be represented by a proper data structure.

Just brainstorming, I'm thinking of something like: (logical structure,
not syntax)

[category]
[param_name]
* param_value
- unit
[param_info]
* url
* short_description
- extra_description
* context
* vartype
- minVal
- maxVal
- enumvals
* min_pg_version
- max_pg_version
- comments
- x-tool-field

where "[]" are nested fields, "*" denotes a field that must always be
present, "-" an optional field and "x-tool-field" a mechanism for
extensions: any tool may use that field(s) to add extra information,
that both postgres and other tools should preserve but may obviously
ignore. There are several use cases that come to my mind for these such
as "version" fields where the history of the param values may be stored
or "audit" fields where the user that changes the values is recorded
with some other audit information (time, etc) for auditing purposes.

IMHO, a data structure like the above would be completely
self-contained and allow any autoconfiguring tool or GUI tool to be
easily created, if the syntax is programmable. It would certainly make
the config file more verbose, but at the same time would help a lot of
users to configure postgres providing much more information.

Makes sense?

Regards,

aht

--
Álvaro Hernández Tortosa

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