Re: DROP ROLE as SUPERUSER

From: Dominique Devienne <ddevienne(at)gmail(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: DROP ROLE as SUPERUSER
Date: 2025-02-21 15:02:24
Message-ID: CAFCRh-8GyM9Vmz68CuuvZv9XC6PKr+1MdOHnys_3kk5qKFFZUA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Feb 21, 2025 at 3:45 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Friday, February 21, 2025, Dominique Devienne <ddevienne(at)gmail(dot)com>
> wrote:
>
>> On Fri, Feb 21, 2025 at 3:33 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
>>> > The point I'm trying to make, is that "hunting down" grantor(s) to
>>> connect
>>> > to DB(s) to be able to "force drop" a ROLE is a PITA. And I really wish
>>> > there
>>> > was an easier way to drop a role in that situation. --DD
>>>
>>> REASSIGN OWNED then DROP OWNED is the recommended path.
>>>
>>
>> Hi. Am I missing something? foobar does not OWN anything in this case.
>> So I don't see how these recommendations are relevant to this particular
>> case. --DD
>>
>
> From “drop owned”:
>
> Any privileges granted to the given roles on objects in the current
> database or on shared objects (databases, tablespaces, configuration
> parameters) will also be revoked.
>
> So, the command does more than the name suggests.
>

OK, thanks Tom and David. I was misled by the name indeed. --DD

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Justin 2025-02-21 21:45:16 Re: Logical decoding
Previous Message David G. Johnston 2025-02-21 14:45:32 Re: DROP ROLE as SUPERUSER