Re: Overhauling GUCS - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Overhauling GUCS
Date
Msg-id Pine.GSO.4.64.0806051452480.27254@westnet.com
Whole thread Raw
In response to Re: Overhauling GUCS  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Overhauling GUCS  (Aidan Van Dyk <aidan@highrise.ca>)
Re: Overhauling GUCS  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-hackers
On Thu, 5 Jun 2008, Alvaro Herrera wrote:

> I must say that I am confused by this thread.  What's the discussed GUC
> overhaul?

http://wiki.postgresql.org/wiki/GUCS_Overhaul

I drop that URL in every other message in hopes that people might start 
commenting on it directly if they see it enough; the fact that you're 
confused says I may need to keep that up :(

> (1) Add a lot more comments to each setting
> (2) Add documentation links to each setting
> (3) Move more frequently used settings to the top of the file
> (4) Ship different sample config files
> (5) Create an expert system to suggest tuning
> (6) Other random ideas (XML, settings in database, others?)
>
> To me, there are two ideas that are doable right now, which are (2) and
> (4).  (1) seems to be a step backwards in pg_hba.conf experience, and we
> would have to maintain duplicate documentation.  (3) seems messy.  (5)
> is a lot of work; do we have volunteers?  As for (6), the two examples I
> give can be easily dismissed.
> (2) and (4) do not seem necessary to get the config API built.

(1) is in that proposal but is strictly optional as something to put in 
the configuration file itself.  The idea behind (2) is to enable tool 
authors to have an easier way to suggest where to head for more 
information.  I'd like for it to be trivial for a tool to say "Suggested 
value for <x> is <y>; see 
http://www.postgresql.org/docs/8.3/interactive/runtime-config-resource.html 
for more information".  I know what most of the settings I tinker with do, 
but even I'd like it to be easier to find the right spot in the manual; 
for newbies it's vital.  You are correct that (2) isn't strictly necessary 
here, but it's valuable and will be easier to wrap into this than to bolt 
on later.

(3) (4) (5) and (6) were off-topic diversions.

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


pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: "ERROR: operator is not unique" with Custom Data Type
Next
From: Robert Lor
Date:
Subject: Re: Overhauling GUCS