Section 1 of 3 · 6 minutes
Separate login roles from permission groups
Your goal
What you will be able to do
Explain how login roles inherit access from group roles and object ownership.
Why this matters at work
The practical reason
A role may have more access than its direct grants show because membership and ownership also matter.
Learn
The idea in plain English
PostgreSQL uses roles for both people and services. A role with LOGIN can connect. A role without LOGIN can act as a permission group that other roles join.
Membership can pass privileges to a login role. Object owners also have powerful control. Review membership, ownership, and direct grants together before changing access.
Remember these points
- LOGIN controls whether a role can connect.
- Group roles collect privileges for several members.
- Ownership is separate from ordinary GRANT statements.
See it in SQL
List role memberships
See which login roles inherit privileges from group roles.
SELECT
member_role.rolname AS member_role,
granted_role.rolname AS granted_role
FROM pg_auth_members AS membership
JOIN pg_roles AS member_role
ON member_role.oid = membership.member
JOIN pg_roles AS granted_role
ON granted_role.oid = membership.roleid
ORDER BY member_role.rolname, granted_role.rolname;This query uses catalog role identifiers to show membership in readable names.
A membership is evidence of possible inherited access, but you must still inspect the privileges held by the granted role.
One row per membership showing the member role and the role whose access it can inherit.
Useful words
Important terms
- Role membership
- A relationship that lets one role use privileges granted to another role.
Quick check · Not graded
Check your understanding
Why can a role have access that is not shown in its direct grants?
Your progress is saved to your signed-in account.