Date: Mon, 2 Jun 2008 14:35:48 +0200
From: "Stephen R. van den Berg" <srb@cuci.nl>
To: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Message-ID: <20080602123548.GA1590@cuci.nl>
References: <48409D1E.3070208@agliodbs.com>
	<200806010032.53337.peter_e@gmx.net>
	<Pine.GSO.4.64.0806020452220.26912@westnet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.64.0806020452220.26912@westnet.com>
User-Agent: Mutt/1.5.13 (2006-08-11)

Greg Smith wrote:
>Joshua has been banging a drum for a while now that all this data needs to 
>get pushing into the database itself.  The GUCS data is clearly structured 

>tables, you'll open up the potential to add a whole new class of 
>user-friendly applications for making configuration easier to manage.

>However, I don't fully agree with taking that idea as far as Joshua has 
>suggested (only having the config data in the database), because having 
>everything in a simple text file that can be managed with SCM etc. has 
>significant value.  It's nice to allow admins to be able to make simple 
>changes with just a file edit.  It's nice that you can look at all the 
>parameters in one place and browse them.  However, I do think that the 
>internal database representation must be capable of holding everything in 
>the original postgresql.conf file and producing an updated version of the 
>file, either locally or remotely, as needed.

Depending on the complexity you want to have inside the generator, one
could imagine a middle ground solution like:

include "database-generated.conf"
include "local-overrides.conf"

Where the "database-generated.conf" does not necessarily needs a lot of
comments.

>Josh has the actual brains behind such an app all planned out if you look 
>at his presentations, but without the larger overhaul it's just not 
>possible to make the implementation elegant.

IMHO Greg's response is the most comprehensive and well-thought-through
contribution in the whole GUC thread.
-- 
Sincerely,
           Stephen R. van den Berg.