Greetings,
* Robert Haas (robertmhaas@gmail.com) wrote:
> On Mon, May 3, 2021 at 2:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > I'm still of the opinion that slicing and dicing this at the per-GUC
> > level is a huge waste of effort. Just invent one role that lets
> > grantees set any GUC, document it as being superuser-equivalent,
> > and be done.
>
> If you want to grant someone full superuser rights, you can do that
> already. The trick is what to do when you want someone to be able to
> administer the cluster in a meaningful way without giving them full
> superuser rights.
I would suggest that both are useful, but the one-big-hammer does
nothing to answer the use-case which was brought up on this particular
thread (which is also certainly not the first time this has been
desired). Instead, I would imagine that there would be a set of
predefined roles for the capabilities and then we might have another
role which is akin to 'pg_monitor' but is 'pg_admin' which is GRANT'd a
bunch of those capabilities and explicitly documented to be able to
become a superuser if they wished to.
Perhaps we would also have a "pg_notsuperuser_admin" which would be
GRANT'd all the capabilities, excluding the ones that could be used to
gain superuser access.
As has also been discussed recently, one of the big missing capabilities
for a "pg_notsuperuser_admin" is a 'create role' capability. I realize
that's not exactly the same as GUCs but it's a big part of what's
missing to make all of this "run a service where the 'DBA' can do
everything except get out to the OS" stuff work out of the box.
Thanks,
Stephen
