Re: Overhauling GUCS - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: Overhauling GUCS
Date
Msg-id 4846A483.8000001@pse-consulting.de
Whole thread Raw
In response to Re: Overhauling GUCS  (Decibel! <decibel@decibel.org>)
Responses Re: Overhauling GUCS  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Overhauling GUCS  ("David E. Wheeler" <david@kineticode.com>)
Re: Overhauling GUCS  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Decibel! wrote:
>>
>> There's no reason that the server has to deal with a text file. I
>> completely agree that there must be a method to change settings even if
>> the database isn't running, but that method does not necessarily need to
>> be a text file. If we can come up with a standard API for reading and
>> writing config changes, we (or anyone else) can write any number of
>> tools to deal with the settings. And once we have an API, we can provide
>> a SQL interface on top of it.
Once in a lifetime, a man should plant a tree, father a child, and write 
an editor... :-)
Hiding the storage of config parameters opaquely behind an API is 
something I've been hating for a long time on win32.

When reading this thread, I'm wondering if anybody ever saw a config 
file for a complex software product that was easily editable and 
understandable. I don't know one. If there was one, it'd be nice to know 
it so we can learn from it.

IMHO the best compromise in machine and human readability is an XML 
format. It's easily decorateable with comments, easily interpreted and a 
pg_settings view could enhance it with even more comments, so an editor 
using pgsql functions (to read and write postresql.conf.xml) could be 
enabled to supply comprehensive help.

Regards,
Andreas






pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Change lock requirements for adding a trigger
Next
From: Tom Lane
Date:
Subject: Re: keyword list/ecpg