Re: REVOKE ALL ON ALL OBJECTS IN ALL SCHEMAS FROM some_role?

From: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
To: Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org>
Subject: Re: REVOKE ALL ON ALL OBJECTS IN ALL SCHEMAS FROM some_role?
Date: 2025-07-08 12:59:50
Message-ID: CANzqJaDuyYD2Pqzng_MqEM2BN02wcQOKqz2ntV0GFs4sV2RVyA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Tue, Jul 8, 2025 at 8:53 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
wrote:

> 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
> have worked
> > for your use case?
>
> If dropping the role is the reason why the privileges should go, the
> canonical
> 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*
>

That scares me. Just like "and privileges" is an unexpected addition to
DROP OWNED (who thinks that grants are owned by the grantee?), REASSIGN
OWNED BY might have some unexpected exceptions.

Cascading statements really need a DRY RUN option.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2025-07-08 13:17:57 Re: REVOKE ALL ON ALL OBJECTS IN ALL SCHEMAS FROM some_role?
Previous Message Laurenz Albe 2025-07-08 12:53:03 Re: REVOKE ALL ON ALL OBJECTS IN ALL SCHEMAS FROM some_role?