From: Tom Lane <tgl@sss.pgh.pa.us>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: Michael Nacos <m.nacos@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Overhauling GUCS
Date: Mon, 18 Aug 2008 15:40:24 -0400
Message-ID: <3447.1219088424@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, stark@enterprisedb.com, gsmith@gregsmith.com, m.nacos@gmail.com
Subject: Re: Overhauling GUCS
In-Reply-To: <3447.1219088424@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox