> On Oct 7, 2021, at 11:30 AM, Stephen Frost <sfrost@snowman.net> wrote:
>
>> Because we've already decided how object ownership works. I didn't write any code to have roles get dropped when
theirowners get dropped. I just put ownership into the system and this is how it naturally works. So you are
advocatingthat 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
makesso 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
ROLEbob CASCADE must revoke "bob" from other roles, must remove "bob", and must not fail. How do you handle this?
CREATE ROLE bob;
GRANT CREATE ON DATABASE regression TO bob;
SET SESSION AUTHORIZATION bob;
CREATE SCHEMA bobs_schema;
RESET SESSION AUTHORIZATION;
DROP ROLE bob CASCADE;
You can't have bobs_schema have a null owner, nor can you refuse to drop bob. Do you just decide that the role
dropping"bob" automatically become the new owner of bobs_schema? Do you assign it to the database owner? What do you
do? And whatever you say we should do, how is that more spec compliant than what I propose we do? I would expect the
argumentagainst X performing X+Y would cut against anything you suggest as much as it cuts against what I suggest.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company