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