Re: DROP ROLE blocked by pg_init_privs
| От | immerrr again |
|---|---|
| Тема | Re: DROP ROLE blocked by pg_init_privs |
| Дата | |
| Msg-id | CAERznn-LSryEQuQAgMTZXYPi9NA-4M28VnOBVt0A4Uaxxwij+w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: DROP ROLE blocked by pg_init_privs (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: DROP ROLE blocked by pg_init_privs
Re: DROP ROLE blocked by pg_init_privs |
| Список | pgsql-general |
Hi Tom,
On Wed, Nov 26, 2025 at 1:08 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> The missing step here is
> > DROP OWNED BY test_role;
> ...
> See discussion here:> ...
I had gone through that thread before posting, and yes, I mentioned "DROP OWNED BY" in my original message. Is this what everyone is doing these days? People just make sure there are no pg_depends/pg_shdepends that need transferring, and then just blast the rest with "DROP OWNED BY"?
It just makes me uneasy to run a command with such potential for data loss in order to remove a role. 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]). They seem to unblock dropping the role for now, but I'm not even sure if I have missed something, or for how long they will keep working.
I guess, my question is shouldn't there be a "REVOKE INITIAL ... FROM <user>" command to drop just the initial privilege(-s) without potentially nuking everything else owned by that user?
Thanks
В списке pgsql-general по дате отправления: