On Thursday, August 29, 2013, Andres Freund wrote:
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.
That's clearly fixable.
> 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?!
Having 400 emails about it means it's contentious. That's quite different from having a large demand. It does speak to the author's persistence as well, but that shouldn't be a surprise.
Also, doing it the adminpack way lacks even the most basic validity
checks. And that's not really changeable.
I don't see why..? Admin pack could certainly be modified to take a parameter and do appropriate verification before locking an object and rewriting the file. It's what we're being expected to do in core, after all. Indeed, we can't even do validity checks on all the options, which is the crux of what I'm concerned about.
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.
Yet no one has tried to improve admin pack?
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.
This completely misses, or perhaps just ignores, the point. Disallowing super user access can be difficult because there's a lot of *normal* DBA activities which can't be easily done without it (like changing table ownership or similar). The "createrole" option definitely improved things but we aren't there yet. It's certainly easy to simply not install the adminpack. The other concerns above are strawmen because they attack a malicious DBA. I'm not talking about malicious DBAs but rather a generally knowledgable DBA who changed shared_buffers up too high and then leaves on vacation, while the OPs guys need to do a database restart for whatever reason and then discover it doesn't start.
I bring up these concerns because I have environments where I can see exactly this happening and I have a hard time believing that I'm somehow alone.
Thanks,
Stephen
