To: Gregory Stark <stark@enterprisedb.com>
cc: "Greg Smith" <gsmith@gregsmith.com>, "Michael Nacos" <m.nacos@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS 
In-reply-to: <87y72u178j.fsf@oxford.xeocode.com> 
References: <7473.1212625397@sss.pgh.pa.us>
	<200807161530.m6GFUNY28751@momjian.us>
	<407fa4640808130738s3537ca45j22322a5eb70f9173@mail.gmail.com>
	<Pine.GSO.4.64.0808171610220.22642@westnet.com>
	<407fa4640808180426q26a41cv817deb91dbbcd312@mail.gmail.com>
	<Pine.GSO.4.64.0808181250190.17947@westnet.com>
	<87y72u178j.fsf@oxford.xeocode.com>
Comments: In-reply-to Gregory Stark <stark@enterprisedb.com>
	message dated "Mon, 18 Aug 2008 19:57:32 +0100"
Date: Mon, 18 Aug 2008 15:40:24 -0400
Message-ID: <3447.1219088424@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Gregory Stark <stark@enterprisedb.com> writes:
> The entire target market for such a thing is DBAs stuck on hosted databases
> which don't have shell access to their machines. Perhaps the overlap between
> that and the people who can write a server-side module which dumps out a
> config file according to some rules is just too small?

There's a veritable boatload of stuff we do that assumes shell access
(how many times have you seen cron jobs recommended, for instance?).
So I'm unconvinced that "modify the config without shell access"
is really a goal that is worth lots of effort.  In any case, there's
already adequate support for sucking postgresql.conf out of the machine
and putting it back: pg_read_file(), pg_file_write(), pg_reload_conf().
So at the end of the day remote access isn't a factor in this at all.

> I do think you and others make it less likely every time you throw up big
> insoluble problems like above though. As a consequence every proposal has
> started with big overly-complex solutions trying to solve all these incidental
> issues which never go anywhere instead of simple solutions which directly
> tackle the main problem.

The impression I get every time this comes up is that various people
have different problems they want to solve that (they think) require
redesign of the way GUC works.  Those complicated solutions arise from
attempting to satisfy N different demands simultaneously.  The fact that
many of these goals aren't subscribed to by the whole community to begin
with doesn't help to ease resolution of the issues.

			regards, tom lane