Re: DROP ROLE blocked by pg_init_privs

immerrr again <immerrr(at)gmail(dot)com> writes:
> On Wed, Nov 26, 2025 at 1:08 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The missing step here is
>> DROP OWNED BY test_role;

> It just makes me uneasy to run a command with such potential for data loss
> in order to remove a role.

Well,

(a) if you try to DROP ROLE any role that still owns objects,
it will refuse, and tell you what the role still owns.
(The crux of your problem is that access permissions are not objects.)

(b) the usual procedure is to do REASSIGN OWNED first. Anything
that remains to be dropped by DROP OWNED must be an access permission
not an object.

(c) you do know that DDL in Postgres is transactional, right?
You can roll it back if you don't like the results.

> So much so that I have written a couple of
> queries to manually clean up the system tables pg_init_privs/pg_shdepends
> instead (see [1]).

Yup, that's far safer. No possibility of irretrievably hosing your
database through ill-considered manual catalog changes, for sure.

regards, tom lane