Podczas korzystania z REASSIGN istnieją bardzo nieintuicyjne wymagania dotyczące uprawnień .
Odkryłem, że gdy konto superużytkownika nie jest dostępne (jak w przypadku RDS lub Cloud SQL), muszę przypisać rolę docelową do mojej obecnej roli, aby ponownie przypisać lub usunąć posiadane obiekty z roli docelowej. Na przykład, jeśli moim aktywnym użytkownikiem jest postsgres i próbuję usunąć 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
Teraz staje się trochę trudniejsze, jeśli user_a jest członkiem postgres , zwłaszcza jeśli zdarzy się, że dziedziczy to członkostwo przez inną rolę, nazwijmy to 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;
Voila!
Uwaga:jest tu inna szeroko przytaczana i skuteczna odpowiedź:https://sysadmintips.com/services/databases/postgresql-error-permission-denied-to-reassign-objects/ co działa świetnie, o ile jesteś w stanie utworzyć i zalogować się jako nowy użytkownik tymczasowy. Jednak w niektórych kontekstach jest to problem sam w sobie (a ponadto masz do czynienia z dodatkowym porządkiem usuwania tej tymczasowej roli po zakończeniu), więc starałem się tego uniknąć.
