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: Pine.GSO.4.64.0805302257380.20830@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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
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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

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