Skip site navigation (1) Skip section navigation (2)

Re: Overhauling GUCS

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Overhauling GUCS
Date: 2008-05-31 04:11:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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 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 

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(at)gregsmith(dot)com Baltimore, MD

In response to

pgsql-hackers by date

Next:From: Mike RylanderDate: 2008-05-31 06:18:08
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Gurjeet SinghDate: 2008-05-31 03:39:14
Subject: Re: Core team statement on replication in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group