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 [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
