Skip to content

Managing Users

The Users tab lists the database’s login roles and lets you manage them with real DDL — CREATE ROLE, ALTER ROLE, GRANT, REVOKE, DROP ROLE — all recorded in the audit log. Passwords are excluded from audit entries.

The user list

Filter with the Filter users… box. Each row shows a role badge (superuser, admin, createdb, nologin, or a plain role) and five privilege chips — S / I / U / D / X for SELECT, INSERT, UPDATE, DELETE, and DROP. The X chip is worth understanding: AccessVault’s “DROP” privilege is schema CREATE under the hood (PostgreSQL has no grantable DROP — owners can always drop their own objects, and CREATE on a schema is the closest manageable proxy).

The user inspector

Select a user to see:

  • Privileges — a per-schema grid of the five privileges, with an Edit button per schema. Hover a granted cell to see where the grant comes from: a direct grant, inherited from another role, or from PUBLIC.
  • Attributes — Superuser, Create role, Create DB, Login, Bypass RLS, Replication, Inherits, and connection limit.
  • Member Of — role memberships, with an ADMIN badge where the membership carries admin option.
  • Password & Expiry — see below.
  • Owned Objects — everything the role owns, by schema and object type.

Granting and revoking privileges

Click Edit on a schema row to open the privileges editor. Each toggle runs a live GRANT/REVOKE <privilege> ON ALL TABLES IN SCHEMA ... (or CREATE ON SCHEMA for DROP). Inherited and PUBLIC-sourced privileges appear disabled — they can’t be revoked from here; you’d need to change the granting role or PUBLIC itself.

Note the scope: grants apply to all current tables in the schema. They don’t install default privileges for future tables.

Creating and dropping users

  • Add User creates a login role with a username and password. The password goes straight to the database — AccessVault does not store it. (Password expiry is set afterwards, from the inspector.)
  • Drop user (bottom of the inspector) asks for confirmation — “This cannot be undone” — then runs DROP ROLE. PostgreSQL will refuse to drop a role that still owns objects or has privileges granted to it; reassign or drop those first.

Password and expiry

From the inspector’s Password & Expiry section:

  • Change Password — enter the new password and confirm.
  • Password Expiry — set a VALID UNTIL date (confirm to apply), or click Never to set it to infinity.