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 1nS4u4-0007sP-AL for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Mar 2022 22:35:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nS4u2-0004ag-Cr for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Mar 2022 22:35:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nS4u2-0004aX-2i for pgsql-hackers@lists.postgresql.org; Wed, 09 Mar 2022 22:35:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nS4tv-00023A-KL for pgsql-hackers@postgresql.org; Wed, 09 Mar 2022 22:35:29 +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 229MZI3I554135; Wed, 9 Mar 2022 17:35:18 -0500 From: Tom Lane To: "David G. Johnston" cc: Robert Haas , Mark Dilger , Stephen Frost , Joshua Brindle , Andrew Dunstan , PostgreSQL-development Subject: Re: role self-revocation In-reply-to: References: <20220228190923.GJ10577@tamriel.snowman.net> <5984.1646585629@sss.pgh.pa.us> <195958.1646669050@sss.pgh.pa.us> <208419.1646677694@sss.pgh.pa.us> <260619.1646684169@sss.pgh.pa.us> <72EF0179-D0DD-490C-812B-D64BEC5C72D1@enterprisedb.com> <548671.1646861460@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Wed, 09 Mar 2022 15:00:51 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <554133.1646865318.1@sss.pgh.pa.us> Date: Wed, 09 Mar 2022 17:35:18 -0500 Message-ID: <554134.1646865318@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > So CREATE ROLE will assign ownership of AND membership in the newly created > role to the session_user I would NOT have it automatically assign membership in the new role, even though the SQL spec says so. We've not done that historically and it doesn't seem desirable. In particular, it's *really* not desirable for a user (role with LOGIN). > I'm fine with this. It does introduce an OWNER concept to roles and so at > minimum we need to add: > ALTER ROLE foo OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | > SESSION_USER } Agreed. regards, tom lane