Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sriSh-003yBV-Ge for pgsql-general@arkaria.postgresql.org; Fri, 20 Sep 2024 18:34:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sriSe-00BhQd-Cb for pgsql-general@arkaria.postgresql.org; Fri, 20 Sep 2024 18:34:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sriSe-00BhQJ-2C for pgsql-general@lists.postgresql.org; Fri, 20 Sep 2024 18:34:33 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sriSc-000DUJ-Q6 for pgsql-general@postgresql.org; Fri, 20 Sep 2024 18:34:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 48KIYRH72470835; Fri, 20 Sep 2024 14:34:27 -0400 From: Tom Lane To: Robert Haas cc: Laurenz Albe , Dominique Devienne , pgsql-general@postgresql.org Subject: Re: Why no pg_has_role(..., 'ADMIN')? In-reply-to: <2468702.1726856198@sss.pgh.pa.us> References: <42cf78d42a376bf05ca9f5776ad29edc30e784d5.camel@cybertec.at> <2468702.1726856198@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 20 Sep 2024 14:16:38 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2470833.1726857267.1@sss.pgh.pa.us> Date: Fri, 20 Sep 2024 14:34:27 -0400 Message-ID: <2470834.1726857267@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Robert Haas writes: >> I think this already exists. The full list of modes supported by >> pg_has_role() is listed in convert_role_priv_string(). You can do >> something like pg_has_role('alice', 'USAGE WITH ADMIN OPTION'). This >> is not new: it worked in older releases too, but AFAIK it's never been >> mentioned in the documentation. > Surely that's a bad documentation omission. Actually, it's not true that it's entirely undocumented, because the text above the table that describes pg_has_role mentions Optionally, WITH GRANT OPTION can be added to a privilege type to test whether the privilege is held with grant option. But I concur that it's not immediately obvious that that applies to role membership, since we don't use the "grant option" terminology for roles. I'm now inclined to add wording within the pg_has_role entry, along the lines of WITH ADMIN OPTION or WITH GRANT OPTION can be added to any of these privilege types to test whether ADMIN privilege is held (all six spellings test the same thing). regards, tom lane