Chelabase
ManagementRoles

Delete a login role

DELETE
/v1/databases/{id}/branches/{branch_id}/roles/{role}

Deletes a role. Its objects in every database go to successor (never the owner): a role the owner can SET ROLE to that isn't owner-level, reserved or a personal login, or chelabase_orphaned (the default), a powerless role. Databases it owns go to the owner. PUBLIC loses EXECUTE on every routine that moved, and the answer lists the SECURITY DEFINER ones for review. Refused while a data API key uses it (role_in_use, with the keys in keys). The owner can't be deleted. A named successor that would let other roles run the role's SECURITY DEFINER routines or read its views without security_invoker with the successor's rights needs confirm, the current token of the delete's preview (GET …/roles/{role}/delete-preview); the grants are kept. chelabase_orphaned never needs one.

Authorization

bearer
AuthorizationBearer <token>

In: header

Path Parameters

id*string

Database id

Formatuuid
branch_id*string

Branch id

Formatuuid
role*string

Role name

Query Parameters

successor?string

The role the deleted role's objects go to: a role the owner can SET ROLE to that isn't owner-level, reserved or a personal login, or chelabase_orphaned (the default), a powerless role. Its databases go to the owner.

confirm?string

The confirm token of the delete's preview (GET …/roles/{role}/delete-preview), when the move to a named successor exposes routines or views to other roles. Not needed for chelabase_orphaned, nor when nothing is exposed.

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

application/json

curl -X DELETE "https://example.com/v1/databases/497f6eca-6276-4993-bfeb-53cbbbba6f08/branches/497f6eca-6276-4993-bfeb-53cbbbba6f08/roles/string"
{  "reassigned": {    "count": 0,    "definers": [      "string"    ]  },  "successor": "string"}

Change a role PATCH

Changes a role's LOGIN, owner level, attributes or memberships; fields left out stay as they are, and `valid_until: null` clears the expiry. Turning LOGIN on generates a password (read it with the connection details and `role`); turning it off drops the password. `member_of` replaces the list of the role's other memberships (`pg_*` and Chelabase's own groups stay). Works on roles made through the API, and on roles made in SQL that the owner administers; the owner can't be changed. A change starts from the role as SQL left it: SQL controls every role's attributes and memberships. Turning LOGIN on counts toward the branch's login-role cap. Answers with the role, never a password.

Preview a role delete GET

What deleting the role to `successor` would expose: its `SECURITY DEFINER` routines granted to roles other than the successor, and its views without `security_invoker` (and materialized views) granted to anyone but the successor, PUBLIC included. After the delete they run with the successor's rights for those roles. Review them, then pass `confirm` to the delete; a delete to a named successor that exposes something is refused without the current token (`exposure_unconfirmed`). `chelabase_orphaned` (the default) never needs one: its preview lists what it finds with `confirm: null`. Changes nothing. The delete's rules for the role and the successor apply.