Dominique Devienne writes:
> On Fri, Feb 21, 2025 at 3:44 PM Tom Lane wrote:
>> DROP OWNED also removes relevant permission entries (which can be
>> thought of as things owned by the role, if you hold your head at
>> the right angle). See its man page.
> Except when it doesn't... I'm doing the
On Fri, Feb 21, 2025 at 3:44 PM Tom Lane wrote:
> Dominique Devienne writes:
> > On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
> >> 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
Dominique Devienne 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 pa
On Fri, Feb 21, 2025 at 3:45 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Friday, February 21, 2025, Dominique Devienne
> wrote:
>
>> On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
>>
>>> Dominique Devienne writes:
>>> > The point I'm trying to make, is that "hunting down" gr
On Friday, February 21, 2025, Dominique Devienne
wrote:
> On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
>
>> Dominique Devienne 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 wi
Dominique Devienne writes:
> On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
>> 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
On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
> Dominique Devienne 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 situati
On Thu, Feb 20, 2025 at 5:52 PM Tom Lane wrote:
> So grants and revokes are still being done as the object owner by
> default.
>
> Now I'm unclear on exactly what was happening in Dominique's case.
> Was the problematic permission granted by somebody other than the
> database's owner?
>
Here's m
"David G. Johnston" writes:
> On Thu, Feb 20, 2025 at 9:05 AM Tom Lane wrote:
>> It used to be that if a superuser issued GRANT/REVOKE, the operation
>> was silently done as the owner of the affected object.
> That is still the case according to the docs (REVOKE):
[ scratches head ... ] I thou
On Thu, Feb 20, 2025 at 9:21 AM Dominique Devienne
wrote:
> But that's not much better. It's basically like the SET ROLE to the
> GRANTOR I did.
> I guess what I want is GRANTED BY ANYONE! And not have to figure out
> GRANTOR(s).
>
Your stated use case is dropping a role. Does the combination o
On Thursday, February 20, 2025, Dominique Devienne
wrote:
> Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
> did nothing, even with CASCADE, when I was running it as SUPERUSER,
> preventing DROP'ing the ROLE. I had to manually SET ROLE to the GRANTOR, do
> the REVOKE, wh
On Thu, Feb 20, 2025 at 9:05 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thursday, February 20, 2025, Dominique Devienne
> > wrote:
> >> Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
> >> did nothing, even with CASCADE, when I was running it as SUPERUSER,
On Thu, Feb 20, 2025 at 5:05 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thursday, February 20, 2025, Dominique Devienne
> > wrote:
> >> Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
> >> did nothing, even with CASCADE, when I was running it as SUPERUSER,
"David G. Johnston" writes:
> On Thursday, February 20, 2025, Dominique Devienne
> wrote:
>> Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
>> did nothing, even with CASCADE, when I was running it as SUPERUSER,
>> preventing DROP'ing the ROLE. I had to manually SET ROLE
On Thursday, February 20, 2025, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thursday, February 20, 2025, Dominique Devienne
> wrote:
>
>> Hi. Today I was surprised that REVOKE ALL ON DATABASE FROM ROLE silently
>> did nothing, even with CASCADE, when I was running it as SUPERUSER,
15 matches
Mail list logo