Re: Proposal for Allow postgresql.conf values to be changed via SQL

On Tue, Oct 30, 2012 at 5:25 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 10/29/12 6:40 AM, Chris Corbyn wrote:
>> What's the use case of this? It sounds like it will just create a maintenance nightmare where some stuff you expect
tolookup in in postgresql.conf is actually hiding in the .auto file. Assuming only super users/sysadmins would have the
abilityto change things in the config file, wouldn't they be more likely to just do it on the server and edit the .conf
(whichamong other things, keeps it tidy and orderly). 
>
> The use is the ability to manage dozens, or hundreds, of PostgreSQL
> servers via Port 5432.  It would also make writing an auto-configurator
> easier.
>
> I agree that there's not much benefit if you're only managing a single
> PostgreSQL server.  There's a lot of benefit for those of us who have to
> manage a lot of them though.

I rather think that the fact that postgresql.conf has supported an
"include directive" since at least as far back as 8.2 (likely further;
I'll not bother spelunking further into the docs) makes this extremely
troublesome.

We have long supported the notion that this configuration does not
have a Unique Place to be (e.g. - if you use INCLUDE, then there are
at least two possible places).

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.

I imagine it means we'd want to come up with a representation that has
suitable semantics for being written to, make sure it is reasonably
expressive *without* INCLUDE, and establish a migration path between
the old and new forms.  At some point, the old form can be treated as
vestigal, and be dropped.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"