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

Hi Peter, Dimitri, thank you for your comments.

On 03/12/13 22:27, Dimitri Fontaine wrote:
> Peter Eisentraut <peter_e@gmx.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