Re: Orphaned users in PG16 and above can only be managed by Superusers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(at)vondra(dot)me>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Orphaned users in PG16 and above can only be managed by Superusers
Date: 2025-03-19 19:47:56
Message-ID: 799029.1742413676@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Mar 19, 2025 at 2:32 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Perhaps if we implemented RESTRICT/CASCADE here, that would
>> at least make it harder to fall into this trap?

> I have always assumed that the reason DROP ROLE blah CASCADE is not
> implemented is (1) it would have to cascade to objects in other
> databases which we can't do from an implementation perspective and (2)
> cascading from roles to tables would create a terrifying amount of
> room for user error. One could dismiss (2) if one were brave enough,
> but (1) seems like an irreducible problem. No?

Yeah, I don't care for having it cascade to physical objects either.
But our current behavior is "RESTRICT if there are owned objects or
permissions on objects, but auto-CASCADE to role grants". There's
no implementation reason why we couldn't make RESTRICT/CASCADE work
for role grants, and that'd be at least a smidge closer to what the
spec says. It's not clear to me though if that could help for the
concern at hand.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2025-03-19 19:55:53 Re: md.c vs elog.c vs smgrreleaseall() in barrier
Previous Message Tom Lane 2025-03-19 19:42:46 Re: RFC: Additional Directory for Extensions