Re: Role Self-Administration

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Role Self-Administration
Date: 2021-10-07 19:19:02
Message-ID: 20211007191902.GL20998@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Mark Dilger (mark(dot)dilger(at)enterprisedb(dot)com) wrote:
> > On Oct 7, 2021, at 11:30 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> >> Because we've already decided how object ownership works. I didn't write any code to have roles get dropped when their owners get dropped. I just put ownership into the system and this is how it naturally works. So you are advocating that DROP...CASCADE works one way for every object type save one. I think that's an incredibly unclean design. Having DROP...CASCADE work the same way for all ownership relations for all object types without exception makes so much more sense to me.
> >
> > We've decided how object ownership works related to DROP ROLE ...
> > CASCADE..? I don't follow how that is the case. What we *do* have is
> > dependency handling, but that isn't the same as ownership.
>
> We have a concept of objects being owned, and we prohibit the owner being NULL. You've already said upthread that DROP ROLE bob CASCADE must revoke "bob" from other roles, must remove "bob", and must not fail. How do you handle this?

Uh, I didn't say it 'must not fail'.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashwin Agrawal 2021-10-07 19:31:39 Re: storing an explicit nonce
Previous Message Daniel Gustafsson 2021-10-07 19:18:19 Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.