public inbox for [email protected]
help / color / mirror / Atom feedFrom: Pavel Luzanov <[email protected]>
To: David G. Johnston <[email protected]>
Cc: David Zhang <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: psql: Add role's membership options to the \du+ command
Date: Mon, 6 Mar 2023 10:43:22 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKFQuwY9DtC8B-eCpHe39yK+y9LardAyaEz0ccVa_pQ+xBgr2Q@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CAKFQuwYt3ENZoYgY2RBh-U4id_=vntT9uJ83PvxPSsPQ0Cc_Jw@mail.gmail.com>
<[email protected]>
<CAKFQuwbmAFfDw9ScCiOxK4UGf8Z8ny1nDgAn41gOJCeJ76QC4Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAKFQuwYZ3S_A1ZKdnmOv-LueO1683UZf7AocNFTDjwEMLVfMOA@mail.gmail.com>
<[email protected]>
<CAKFQuwbkywHVFPL6TrJiHFd0KgEvdH0LZTSFxAdK4wzP-u8m-A@mail.gmail.com>
<[email protected]>
<CAKFQuwY9DtC8B-eCpHe39yK+y9LardAyaEz0ccVa_pQ+xBgr2Q@mail.gmail.com>
On 03.03.2023 19:21, David G. Johnston wrote:
> I'd be fine with "pg_can_admin_role" being a newly created function
> that provides this true/false answer but it seems indisputable that
> today there is no core-provided means to answer the question "can one
> role get ADMIN rights on another role". Modifying \du to show this
> seems out-of-scope but the pg_has_role function already provides that
> question for INHERIT and SET so it is at least plausible to extend it
> to include ADMIN, even if the phrase "has role" seems a bit of a
> misnomer. I do cover this aspect with the Role Graph pseudo-extension
> but given the presence and ease-of-use of a boolean-returning function
> this seems like a natural addition. We've also survived quite long
> without it - this isn't a new concept in v16, just a bit refined.
I must admit that I am slowly coming to the same conclusions that you
have already outlined in previous messages.
Indeed, adding ADMIN to pg_has_role looks logical. The function will
show whether one role can manage another directly or indirectly (via SET
ROLE).
Adding ADMIN will lead to the question of naming other values. It is
more reasonable to have INHERIT instead of USAGE.
And it is not very clear whether (except for backward compatibility) a
separate MEMBER value is needed at all.
> I wouldn't bother starting yet another thread in this area right now,
> this one can absorb some related changes as well as the subject line item.
I agree.
--
Pavel Luzanov
Postgres Professional:https://postgrespro.com
view thread (29+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: psql: Add role's membership options to the \du+ command
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox