Re: Overhauling GUCS - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Overhauling GUCS
Date
Msg-id Pine.GSO.4.64.0805302257380.20830@westnet.com
Whole thread Raw
In response to Overhauling GUCS  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On Fri, 30 May 2008, Josh Berkus wrote:

> 1) Add several pieces of extra information to guc.c in the form of extra 
> "gettext" commands:  default value, subcategory, long description, 
> recommendations, enum lists.
> 2) Incorporate this data into pg_settings

When you last brought this up in February (I started on a long reply to 
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00759.php that I 
never quite finished) the thing I got stuck on was how to deal with the 
way people tend to comment in these files as they change things.

One problem I didn't really see addressed by the improvements you're 
suggesting is how to handle migrating customized settings to a new version 
(I'm talking about 8.4->9.0 after this is in place, 8.3->8.4 is a whole 
different problem).  It would be nice to preserve "history" of what people 
did like in your examples (which look exactly like what I find myself 
running into in the field).  Now, that will get a lot easier just by 
virtue of having a smaller config file, but I think that adding something 
into pg_settings that allows saving user-added commentary would be a nice 
step toward some useful standardization on that side of things.  It would 
make future automated tools aimed at parsing and generating new files, as 
part of things like version upgrades, a lot easier if there was a standard 
way such comments were handled in addition to the raw data itself.

The other thing I'd like to see make its way into pg_settings, so that 
tools can operate on it just by querying the database, is noting what file 
the setting came from so that you can track things like include file 
usage.  I think with those two additions (comments and source file 
tracking) it would even be concievable to clone a working facsimile of 
even a complicated postgresql.conf file set remotely just by reading 
pg_settings.

While a bit outside of the part you're specifically aiming to improve 
here, if you could slip these two additions in I think it would be a boon 
to future writers of multi-server management tools as well.

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


pgsql-hackers by date:

Previous
From: "Gurjeet Singh"
Date:
Subject: Re: Core team statement on replication in PostgreSQL
Next
From: Dimitri Fontaine
Date:
Subject: Re: Core team statement on replication in PostgreSQL