Re: Proposal for Allow postgresql.conf values to be changed via SQL - Mailing list pgsql-hackers

On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>>> I should think that doing this requires heading back towards there
>>> being a single unique configuration stream, and over the course of
>>> several versions, deprecating the INCLUDE directive.
>
>> Oh, maybe I should take a closer look at Amit's proposal then.  I
>> thought we planned to make use of the INCLUDE facility for SET
>> PERSISTENT, including supporting include-if-exists.  Possibly what he's
>> proposing and what I thought our last consensus were are highly divergent.
>
> I'm not convinced we ever *had* a consensus on this.  There were
> proposals, but I'm not sure a majority ever bought into any one of 'em.

I thought there was a consensus. But given that the one I thought we
had consensus on was different, I'm not sure we can correctly call it
consensus.

What we discussed at that time was to have a *function* that changes
the permanent configuration, and not actually extend the syntax of the
system. As a starting point.

The idea at the time was to use the include *directory* functionality,
for say a "config.d" directory in pgdata. The builtin one would then
use a predictable filename in this directory, so that the DBA who
prefers it can drop files both before and after that file into the
directory.

> The whole problem of intermixing manual editing and programmatic editing
> is just a big can of worms, and not everybody is prepared to give up the
> former to have the latter.
>
> You can, if you are so inclined, implement something functionally
> equivalent to Amit's proposal today using contrib/adminpack's
> pg_file_write --- okay, it's much less convenient than a built-in
> implementation would be, but you can drop some variable assignments into
> a file and then put a suitable INCLUDE into the otherwise-static main
> config file.  The fact that this isn't being done by a large number of
> people (is anybody at all actually doing it?) suggests to me that maybe
> the demand isn't all that great.

The demand for running something like thta manually isn't all that
great, I believe. This is why I think using a function for it is
perfectly OK, and we don't necessarily need ALTER SYSTEM or something
like that. (In fact, a function might be preferred in many cases since
you can feed it the result of a query, unlike an ALTER statement). But
a standardized way for how it's dealt with so that multiple tools
don't step on each other is a very good idea - and probably one reason
people don't build this stuff themselves.


Being able to automate it across many machines is bigger, but most
people solve that today with things like puppet and chef.

Being able to build a nice configuration interface into something like
pgadmin is something that a lot of people ask for - but that's at best
a secondary effect from having a change like this, which is why we're
not seeing direct demand for it.


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/