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
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 |