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