> On Oct 5, 2021, at 10:20 AM, Stephen Frost <sfrost@snowman.net> wrote:
>
> Greetings,
>
> On Tue, Oct 5, 2021 at 13:17 Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> > On Oct 5, 2021, at 10:14 AM, Stephen Frost <sfrost@snowman.net> wrote:
> >
> > What does the “ownership” concept actually buy us then?
>
> DROP ... CASCADE
>
> I’m not convinced that we need to invent the concept of ownership in order to find a sensible way to make this work-
thoughit would be helpful to first get everyone’s idea of just what *would* this command do if run on a role who “owns”
orhas “admin rights” of another role?
Ok, I'll start. Here is how I envision it:
If roles have owners, then DROP ROLE bob CASCADE drops bob, bob's objects, roles owned by bob, their objects and any
rolesthey own, recursively. Roles which bob merely has admin rights on are unaffected, excepting that they are
administeredby one fewer roles once bob is gone.
This design allows you to delegate to a new role some task, and you don't have to worry what network of other roles and
objectsthey create, because in the end you just drop the one role cascade and all that other stuff is guaranteed to be
cleanedup without any leaks.
If roles do not have owners, then DROP ROLE bob CASCADE drops role bob plus all objects that bob owns. It doesn't
cascadeto other roles because the concept of "roles that bob owns" doesn't exist. If bob created other roles, those
willbe left around. Objects that bob created and then transferred to these other roles are also left around.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
