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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-06-04 14:21:19 Re: keyword list/ecpg
Previous Message Decibel! 2008-06-04 13:31:46 Re: Change lock requirements for adding a trigger