Spoiler alert: I am aware that a similar question has been asked before, yet I am using Azure PosgreSQL Flexible server, which means that I do not have superuser access to Postgresql (as it is a managed service, and only Azure has superuser permissions).
Here is the problem:
We have some dynamically created DB roles in postgresql which get Connection permissions to a DB and additional permissions (insert, update etc.) on all Tables in the public schema of that DB.
The create statement used for these roles is:
CREATE USER "test" WITH LOGIN PASSWORD 'somepasswordyoudonotneedtoknow' VALID UNTIL '2024-05-03 20:02:25+00';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "test";
GRANT CONNECT ON DATABASE "myDB" TO "test";
That seems to work fine so far.
We use the role to connect to the DB and execute some select statements.
Now after the role expired we want to remove it again, by revoking access and dropping the role:
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA public FROM "test";
REVOKE ALL PRIVILEGES ON DATABASE "myDB" FROM "test";
DROP ROLE IF EXISTS "test";
The first two statements execute without an error, but the DROP ROLE fails with:
ERROR: privileges for database myDBrole "test" cannot be dropped because some objects depend on it
ERROR: role "test" cannot be dropped because some objects depend on it
SQL state: 2BP01
Detail: privileges for database myDB
This indicates that the user still has some privileges on the database itself, but the REVOKE ALL PRIVILEGES ON DATABASE did not return any error.
When I then check the permissions for the database using pgAdmin (4.8) I can see on the security tab of the DB properties, that the role still has connect permissions on the DB.
Even when I try to delete this entry and save (no error shows up), then open the properties again, the role still has “c” (connect) permissions.
So I am not sure what is going on, and why no errors ware shown then trying to revoke CONNECT access to the database in the first place.
All other statements I tried to transfer all OWNER ship of this role failed since I do need superuser permissions for that, which Azure does not give to clients in the managed Solution.
Any ideas?