Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review]) - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Date
Msg-id CAOuzzgqXRH33r_u4fjNdFAc8UH=zHG==m+K2EL_agsdc-PFCtQ@mail.gmail.com
Whole thread Raw
In response to Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Andres Freund <andres@2ndquadrant.com>)
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Cédric Villemain <cedric@2ndquadrant.com>)
Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Thursday, August 29, 2013, Andres Freund wrote:
On 2013-08-29 15:07:35 -0400, Robert Haas wrote:
> I don't really see a compelling reason why it can't or shouldn't be in
> core.  But having something better in contrib would still be an
> improvement on the status quo.

I don't see much argument for putting it into contrib. One class of
users this will benefit is relatively new ones, possibly using some
GUI. Adding some additional complexity for them to enable the feature
seems pointless to me.

I keep wondering what this fantastic new GUI that isn't pgAdmin is, and why it wouldn't be able to use the exact same mechanism that pgAdmin uses and provides in a few simple steps to enable this. 
 
If you don't want your installation to use it, tell you ops people not
to do so. They are superusers, they need to have the ability to follow
some rules you make up internally.

The OPs people are the ones that will be upset with this because the DBAs will be modifying configs which OPs rightfully claim as theirs. If they have a way to prevent it then perhaps it's not terrible but they'd also need to know to disable this new "feature". As for ALTER DATABASE- I would be happier with encouraging use of that (or providing an ALTER CLUSTER) for those thing it makes sense and works for and removing those from being in postgresql.conf. I still feel things like listen_addresses shouldn't be changed through this. 
 
The energy wasted in a good part of this massive 550+ messages thread is
truly saddening. We all (c|sh)ould have spent that time making PG more
awesome instead.

Perhaps not understood by all, but keeping PG awesome involves more than adding every feature proposed- it also means saying no sometimes; to features, to new GUCs, even to micro-optimizations when they're overly complicated and offer only minimal or questionable improvements. 

Thanks,

Stephen 

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Variadic aggregates vs. project policy
Next
From: Andrew Dunstan
Date:
Subject: Re: Variadic aggregates vs. project policy