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