DROP USER deletes a user. At the same time, it deletes the schema having the same name as the user.
In DWS, the enable_kill_query configuration parameter exists in the postgresql.conf file. This parameter affects the action of deleting user objects using CASCADE.
- When enable_kill_query is on and CASCADE is used to delete user objects, the processes will be automatically killed and the user will be deleted.
- When enable_kill_query is off and CASCADE is used to delete user objects, the user will be deleted after the processes are automatically killed.
- CASCADE is used to delete objects (excluding databases) that depend on the user. CASCADE cannot delete locked objects unless the locked objects are unlocked or the processes that lock the objects are killed.
- When deleting a user in the database, if the object that the user depends on is in another database or the object of the dependent user is another database, you need to manually delete the dependent objects in other databases or delete the dependent database. Then, delete the user. Cross-database cascading deletion cannot be performed.
- In a multi-tenant scenario, the service user will also be deleted when you delete a user group. If the specified CASCADE concatenation is deleted, CASCADE is specified upon the deletion of the service user. If you fail to delete a user, an error is reported, and you cannot delete other users either.
- If the user has an error table specified when the GDS foreign table is created, the user cannot be deleted by specifying the CASCADE keyword in the DROP USER command.
DROP USER [ IF EXISTS ] user_name [, ...] [ CASCADE | RESTRICT ];
- IF EXISTS
Sends a notice instead of an error if the specified user does not exist.
Specifies the name of a user to be deleted.
Value range: An existing user name.
- CASCADE | RESTRICT
- CASCADE: automatically deletes all objects that depend on the user to be deleted.
- RESTRICT: refuses to delete the user if any objects depend on it. This is the default.