Existem alguns requisitos de permissão muito pouco intuitivos ao usar
REASSIGN . Descobri que quando uma conta de superusuário não está disponível (como no caso do RDS ou Cloud SQL), preciso conceder o papel de destino ao meu papel atual para reatribuir ou descartar objetos de propriedade do papel de destino. Por exemplo, se meu usuário ativo for
postsgres , e estou tentando remover user_a :> DROP OWNED BY user_a
ERROR: permission denied to drop objects
> GRANT user_a TO postgres;
GRANT ROLE
> DROP OWNED BY user_a;
DROP OWNED
Agora, fica um pouco mais complicado se
user_a acontece de ser um membro do postgres , especialmente se herdar essa associação por meio de outra função, vamos chamá-la de schema_admin ... > DROP OWNED BY user_a
ERROR: permission denied to drop objects
> GRANT user_a TO postgres;
ERROR: role "user_a" is a member of role "postgres"
-- Alright, let's try to revoke it...
> REVOKE postgres FROM user_a;
REVOKE ROLE
> GRANT user_a TO postgres;
ERROR: role "user_a" is a member of role "postgres"
-- It's still a member through the inherited grant - trying to revoke again doesn't work:
> REVOKE postgres FROM user_a;
WARNING: role "user_a" is not a member of role "postgres"
REVOKE ROLE
-- So you have to identify the role it's inheriting from, and revoke that:
> REVOKE schema_admin FROM user_a;
REVOKE ROLE
> GRANT user_a TO postgres;
GRANT ROLE
-- Now just to be safe, I'll reassign owned objects before actually dropping everything:
> REASSIGN OWNED BY user_a TO postgres;
REASSIGN OWNED
> DROP OWNED BY user_a;
DROP OWNED
> DROP ROLE user_a;
DROP ROLE;
Voilá!
Observação:há outra resposta amplamente referenciada e eficaz aqui:https://sysadmintips.com/services/databases/postgresql-error-permission-denied-to-reassign-objects/ que funciona muito bem, desde que você possa criar e fazer login como um novo usuário temporário. No entanto, em alguns contextos, isso é um problema em si (e você também tem a limpeza extra para remover essa função temporária quando terminar), então tentei evitar isso aqui.
