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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers