Date: Sun, 17 Aug 2008 18:12:50 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS 
In-Reply-To: <26969.1219007935@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.64.0808171740020.22642@westnet.com>
References: <7473.1212625397@sss.pgh.pa.us>
	<200807161530.m6GFUNY28751@momjian.us>
	<407fa4640808130738s3537ca45j22322a5eb70f9173@mail.gmail.com>
	<Pine.GSO.4.64.0808171610220.22642@westnet.com>
	<26969.1219007935@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sun, 17 Aug 2008, Tom Lane wrote:

> What we have now was named Grand Unified Configuration for a reason:
> it centralized the handling of what had been a mess of different things
> configured in different ways.  I'm not eager to go backwards on that.

No need to change anything related to how the configuration is done. 
There's really only two things wrong with what's there right now IMHO and 
they don't require any changes to the internals, just what's shown:

1) The view should show both how the user defined the setting and how it's 
represented internally.  Basically something that looks like this:

select name,current_setting(name) as input_setting,setting from 
pg_settings;

2) Expose the default value.

> I'm also interested to know exactly what such a table would provide
> that isn't already available in the form of the pg_settings view.

Links to the relevant documentation and a place to save both default and 
user comments about the setting were two things being considered that 
seemed a really bad fit to tack onto the GUC structure.  There's some 
others.  The main point is that that nobody wants to have to tinker with 
the core GUC itself just to decorate it with more information, that is 
complicated enough as it is.

One might make a case that the stuff the GUC must handle (settings, units, 
type, defaults, etc.) could be usefully separated from all the more 
documentation-oriented bits stored there right now (category, 
descriptions), and that the existing documentation bits could move over to 
the table along with the hyperlinks and such.  Doing that adds another 
place to have to edit, but I think there's an even exchange available 
there because it enables easy auto-generation of the postgresql.conf file 
at initdb time from that table + pg_settings.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD