Re: RFC: programmable file format for postgresql.conf
От | Álvaro Hernández Tortosa |
---|---|
Тема | Re: RFC: programmable file format for postgresql.conf |
Дата | |
Msg-id | 529ECEC6.1050405@nosys.es обсуждение исходный текст |
Ответ на | Re: RFC: programmable file format for postgresql.conf (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: RFC: programmable file format for postgresql.conf
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Claudio FreireДата:
Сообщение: Re: Parallel Select query performance and shared buffers