Message-ID: <bacddcb84956a662cd3de97ce4fe32d705083dc7.camel@cybertec.at>
Subject: Re: REVOKE ALL ON ALL OBJECTS IN ALL SCHEMAS FROM some_role?
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Scott Ribe <scott_ribe@elevated-dev.com>, Ron Johnson
	 <ronljohnsonjr@gmail.com>
Cc: Pgsql-admin <pgsql-admin@lists.postgresql.org>
Date: Tue, 08 Jul 2025 14:53:03 +0200
In-Reply-To: <D1C4B519-67B6-446A-92DF-A33D095FD215@elevated-dev.com>
References: 
	<CANzqJaDu+7q9i=-vwUsX-ZZRTKSCCCG7FVF32X7XhPo1E4Xpxg@mail.gmail.com>
	 <D1C4B519-67B6-446A-92DF-A33D095FD215@elevated-dev.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/bacddcb84956a662cd3de97ce4fe32d705083dc7.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-07-08 at 06:16 -0600, Scott Ribe wrote:
> I don't have an answer for you, just a question out of curiosity. Is this=
 a prelude
> to dropping the role? Thus, if it existed, DROP ROLE ... CASCADE would ha=
ve worked
> for your use case?

If dropping the role is the reason why the privileges should go, the canoni=
cal
procedure is:

- connect to each database in the cluster in turn; in each:
  - REASSIGN OWNED BY role_to_drop ...
    to transfer ownership
  - DROP OWNED BY role_to_drop
    to remove owned objects *and privileges*
- DROP ROLE role_to_drop

Yours,
Laurenz Albe