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

On 2013-08-29 18:42:13 -0400, Stephen Frost wrote:
> On Thursday, August 29, 2013, Andres Freund wrote:
> > 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.

But that doesn't mean that endlessly discussing in circles is a
worthwile thing to do. The discussion essentially hasn't progressed
towards concensus in the last months at all besides involving most
active hackers at some point. If anything it has become more
contentious.

Obviously lots of people have strong opinions. Now we need to make
decisions. Even if it ends up being ones I judge to be ridiculously bad.

> > 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.

To quote Robert two mails up:

> Huh?  The problem with adminpack is that it doesn't let you modify
> individual configuration settings.  All you can do is rewrite an
> entire file.  I guess somebody could write a specialized client that
> just uses that infrastructure to rewrite postgresql.conf.  For all I
> know, someone has.  Even if not, I don't think that you can use that
> to prove that people don't care about this feature.  If nobody cares,
> why are there 400 emails on this topic?!

Also, doing it the adminpack way lacks even the most basic validity
checks. And that's not really changeable.

Presumably one major reason why we don't have other|good GUIs is that
it's ridicuously hard to make them work to an interesting extent with
the current infrastructure.

> > 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.

If they give out superuser access it has to be to people who can follow
rules. After all they don't DROP DATABASE; DELETE FROM pg_class; alter
passwords; use adminpack (changing postgresql.conf..); ... All of which
they can do.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services