Der er nogle meget uintuitive tilladelseskrav, når du bruger REASSIGN .
Jeg har fundet ud af, at når en superbrugerkonto ikke er tilgængelig (som i tilfældet med RDS eller Cloud SQL), er jeg nødt til at tildele målrollen til min nuværende rolle for at omtildele eller slette ejede objekter fra målrollen. For eksempel, hvis min aktive bruger er postsgres , og jeg forsøger at fjerne 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
Nu bliver det lidt sværere, hvis user_a tilfældigvis er medlem af postgres , især hvis det tilfældigvis arver det medlemskab gennem en anden rolle, lad os kalde det 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!
Bemærk:Der er et andet bredt refereret og effektivt svar her:https://sysadmintips.com/services/databases/postgresql-error-permission-denied-to-reassign-objects/ hvilket fungerer fint, så længe du er i stand til at oprette og logge på som ny midlertidig bruger. Men i nogle sammenhænge er det et problem i sig selv (og så har du også den ekstra oprydning at klare med at fjerne den midlertidige rolle, når du er færdig), så det forsøgte jeg at undgå her.