Message-ID: <4858E7D1.6080401@hagander.net>
Date: Wed, 18 Jun 2008 12:47:45 +0200
From: Magnus Hagander <magnus@hagander.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Greg Smith <gsmith@gregsmith.com>
CC: Heikki Linnakangas <heikki@enterprisedb.com>,
	Alvaro Herrera <alvherre@commandprompt.com>, pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
References: <48409D1E.3070208@agliodbs.com>
	<200806010032.53337.peter_e@gmx.net>
	<Pine.GSO.4.64.0806020452220.26912@westnet.com>
	<17932.1212415926@sss.pgh.pa.us>
	<20080604131810.GH65238@decibel.org>
	<4846A483.8000001@pse-consulting.de>
	<Pine.GSO.4.64.0806041045520.2258@westnet.com>
	<29525.1212613052@sss.pgh.pa.us> <48472E47.7030701@dunslane.net>
	<Pine.GSO.4.64.0806042033120.3874@westnet.com>
	<20080605162400.GF16502@alvh.no-ip.org>
	<48481CBF.6040602@enterprisedb.com> <48481E3A.4010306@hagander.net>
	<Pine.GSO.4.64.0806051321360.27711@westnet.com>
In-Reply-To: <Pine.GSO.4.64.0806051321360.27711@westnet.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greg Smith wrote:
> On Thu, 5 Jun 2008, Magnus Hagander wrote:
> 
>> We really need a "proper API" for it, and the stuff in pgAdmin isn't
>> even enough to base one on.
> 
> I would be curious to hear your opinion on whether the GUC overhaul
> discussed in this thread is a useful precursor to building such a proper
> API.

I'm getting back to this one now that the discussion has died down a bit.

As usual, the discussion spread out into these huge changes needed to be
done to satisfy everyone from day one. I don't think that's the way to
go - we have to do it piece by piece if that's ever going to be done.
IMHO the first thing to do is to create a stable API for modifying
config variables remotely. *at this time* it doesn't matter how this API
modifies the configuration, if it's in a file on in the db or whatever.
We can always change that later...  Which is why I will be proceeding
with this one - make an API that requires the least possible change for
now, per discussions earlier this year (not in this thread) :-)


Now, this in itself is unrelated to the stuff Josh was talking about
which is collecting the information in one place and being able to
generate config files that don't contain everything, and being able to
auto-tune things. It would be nice for such a tool to be able to get the
full descriptions and such from the pg_settings view or such, which
means it needs to go in the code and not in a standalone file, but it's
not *as necessary*.

I still think the config file we ship today is horrible, I get lots of
questions around it, and I see lots of examples of people who tweak
settings they have no idea what they do, just because it's there. That's
 a separate issue that could *either* be solved by shipping more than
one  default config file, or it could be solved by the config file
generator Josh proposed.

//Magnus