>> 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.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2008-06-04 14:21:19|
|Subject: Re: keyword list/ecpg |
|Previous:||From: Decibel!||Date: 2008-06-04 13:31:46|
|Subject: Re: Change lock requirements for adding a trigger|