Re: Orphaned users in PG16 and above can only be managed by Superusers - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Orphaned users in PG16 and above can only be managed by Superusers
Date
Msg-id CAKFQuwa0YUcoPpEsuBb8bVo00+hEYfatcnSWKXHMwU0cd4y5aA@mail.gmail.com
Whole thread Raw
In response to Re: Orphaned users in PG16 and above can only be managed by Superusers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Mar 19, 2025 at 10:28 AM Robert Haas <robertmhaas@gmail.com> wrote:
I in general dislike throwing up barriers that prevent objects from
being dropped. As a user, I find such rules frustrating, especially if
I'm still allowed to accomplish the same drop indirectly by some
series of commands (e.g. REVOKE first, then DROP). If I'm allowed to
do it indirectly, then I should also be allowed to it directly, at
least in cases where there's only one way of fixing the problem that
is preventing me from doing the DROP, which I think is the case here.
For example, if bob owns a tractor and I want to DROP bob but the
tractor is indestructible, then it's reasonable to make the operation
fail. I need to give away bob's tractor before I drop him. But here,
if I say I want to DROP ROLE b, I'm going to have to first REVOKE c
FROM b -- there is no real other alternative. So why not make that
happen automatically? When I say I want to DROP something, I'm
serious: I really want it gone.


I'd rather that intent be communicated through CASCADE than just assumed, but I agree with the general point.

David J.

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: RFC: Additional Directory for Extensions
Next
From: Jeff Davis
Date:
Subject: Re: Update Unicode data to Unicode 16.0.0