Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qDQz3-0001Pq-2P for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Jun 2023 14:44:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qDQz1-0005OT-Tr for pgsql-hackers@arkaria.postgresql.org; Sun, 25 Jun 2023 14:44:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qDQz1-0005OE-EE; Sun, 25 Jun 2023 14:44:55 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by magus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qDQyy-000PHJ-5z; Sun, 25 Jun 2023 14:44:54 +0000 Received: from [192.168.0.104] (unknown [62.217.185.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: p.luzanov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 856B5E2043A; Sun, 25 Jun 2023 17:44:51 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1687704291; bh=yMv/NBUhSd6sfNZeaP1bGAxX2UutmDMSSM6BAIc4T20=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=Z1osOLrPuwFkU2czOQ7h+QEOWOd3fDMxuS2lw8IUU6/PFFpCkr9QwMyOSIsNJZguS KtXsRGsqaN2eWuOdsxzrGTIyYgcnoddlQgVgXQQikl+pODeyWyO/XZ9Bj5+YaKGmdv DTeR0kTPDyi4POIpG/tackuRzAx9yQGlaV//d6BqcSFWdNBa8cacYIxUu3WGRiTs5X o2tzzT/NE+5dTtLetIUr5f0gOBw5NgYPxHOe8J0vSC9SFEw9fcT6ELU4WniYYP1DYU CuRq4MLis+vkIcLcfx8GJsfGFKpqzAPddvS9/yfMVuWOm/KXJDTwiNFZDZMESoqoqq wBggol0P/Xrow== Content-Type: multipart/alternative; boundary="------------MuPWzPG1QIdqnuOtqFQDRlWj" Message-ID: <41517a12-6599-b54b-d30b-3bae906a280b@postgrespro.ru> Date: Sun, 25 Jun 2023 17:44:51 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: psql: Add role's membership options to the \du+ command Content-Language: en-US, ru-RU To: "David G. Johnston" Cc: Tom Lane , "Jonathan S. Katz" , Robert Haas , David Zhang , "pgsql-hackers@lists.postgresql.org" , rmt@lists.postgresql.org, horikyota.ntt@gmail.com References: <2977612.1683131109@sss.pgh.pa.us> <39e7431c-1224-ab05-c67c-68f4cf625442@postgrespro.ru> <6b64c59a-fe41-bb07-d0cd-856896412b00@postgresql.org> <7aa3d663-1ea9-de0d-c13a-cbce83902214@postgrespro.ru> <4128935.1687478926@sss.pgh.pa.us> <105356.1687565531@sss.pgh.pa.us> From: Pavel Luzanov In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------MuPWzPG1QIdqnuOtqFQDRlWj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 24.06.2023 18:57, David G. Johnston wrote: > On Sat, Jun 24, 2023 at 8:11 AM Pavel Luzanov > wrote: > > There are two commands showing the same information about roles: > \du and > \dr. > > > I would add \dr as the new official command to complement adding \drg > and deprecate both \du and \dg.  Though actual removal and > de-documenting doesn't seem like a good idea. But if we ever did > assign something non-role to \dr it would be very confusing. It's my mistake and inattention. I was thinking about '\du' and '\dg', and wrote about '\du' and '\dr'. I agree that \dr and \drg the best names. So, now concentrating on implementing \drg. > * The new meta-command will also make sense for versions <16. > The ADMIN OPTION is available in all supported versions. > > > Doesn't every role pre-16 gain SET permission?  We can also deduce > whether the grant provides INHERIT based upon the attribute of the > role in question. Indeed! I will do so. > > > * The new meta-command will not show all roles. It will only show the > roles included in other roles. > To show all roles you need to add an outer join between pg_roles and > pg_auth_members. > But all columns except "role" will be left blank. Is it worth > doing this? > > > I'm inclined to want this.  I would be good when specifying a role to > filter upon that all rows that do exist matching that filter end up in > the output regardless if they are standalone or not. Ok -- Pavel Luzanov Postgres Professional:https://postgrespro.com --------------MuPWzPG1QIdqnuOtqFQDRlWj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 24.06.2023 18:57, David G. Johnston wrote:
On Sat, Jun 24, 2023 at 8:11 AM Pavel Luzanov <p.luzanov@postgrespro.ru> wrote:
There are two commands showing the same information about roles: \du and
\dr.


I would add \dr as the new official command to complement adding \drg and deprecate both \du and \dg.  Though actual removal and de-documenting doesn't seem like a good idea.  But if we ever did assign something non-role to \dr it would be very confusing.

It's my mistake and inattention. I was thinking about '\du' and '\dg', and wrote about '\du' and '\dr'.
I agree that \dr and \drg the best names.
So, now concentrating on implementing \drg.

* The new meta-command will also make sense for versions <16.
The ADMIN OPTION is available in all supported versions.

Doesn't every role pre-16 gain SET permission?  We can also deduce whether the grant provides INHERIT based upon the attribute of the role in question.

Indeed! I will do so.



* The new meta-command will not show all roles. It will only show the
roles included in other roles.
To show all roles you need to add an outer join between pg_roles and
pg_auth_members.
But all columns except "role" will be left blank. Is it worth doing this?


I'm inclined to want this.  I would be good when specifying a role to filter upon that all rows that do exist matching that filter end up in the output regardless if they are standalone or not.

Ok

-- 
Pavel Luzanov
Postgres Professional: https://postgrespro.com
--------------MuPWzPG1QIdqnuOtqFQDRlWj--