Skip site navigation (1) Skip section navigation (2)

Re: Overhauling GUCS

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: "Decibel!" <decibel(at)decibel(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <gsmith(at)gregsmith(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Overhauling GUCS
Date: 2008-06-04 14:19:47
Message-ID: 4846A483.8000001@pse-consulting.de (view raw or flat)
Thread:
Lists: 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





In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group