Hi all, First-time hacker here wanting to get into the community.
I am proposing a fairly small quality of life feature for role management which is to allow users to reassign ownership within the same command as dropping a role. Currently you must reassign ownership prior to dropping a role (if it owns anything) such as: REASSIGN OWNED BY role1 [, ...]TO role2; DROP ROLE role1; I am thinking of the usage: DROP ROLE role1 [, ...] REASSIGN OWNED TO role2; Original behavior would remain if not specifying the option: DROP ROLE role1 [, ...]; For the implementation, I was thinking of adding a RoleSpec into DropRoleStmt to hold the "assigned to role" which would be NULL unless otherwise provided by the option. The grammar for DropRoleStmt would be updated to add a new option (opt_reassign) to optionally provide the RoleSpec. There are other cases in the DropRoleStmt grammar such as users and groups - I'm wondering if this would apply to those as well (e.g., DROP USER ..., DROP GROUP ...) Within the DropRole command (after all the initial validity checks,) I was thinking to check if this value was non-null and create a ReassignOwnedStmt before making a call to ReassignOwnedObjects before the foreach loop is called to actually remove the list of roles. My one concern is the possible failure mode - is it possible for the reassignment to work but the role to fail to drop? Is this preventable? I'm not sure how to "cleanly" approach this type of safety where I can assure that both of these operations must succeed rather than reassigning ownership and failing to drop a role. Are there any other failure modes I should be considering? Would like to hear from anyone if there's any appetite for this and your thoughts on how this can be approached. Regards, - Zach Weaver
