作为一名数据库管理员或后端开发人员，你是否曾经在调试数据库连接问题时，迫切需要确认某个用户是否存在？或者在进行安全审计时，需要快速梳理当前数据库实例中的所有权限分配？在 PostgreSQL 的日常运维和开发中，管理用户及其相应的权限是保障数据安全和维护系统秩序的核心任务。了解如何高效地列出用户、查看他们的角色属性以及掌握底层的查询机制，不仅能帮助我们排查问题，更是构建安全数据库环境的基石。
在这篇文章中，我们将深入探讨 PostgreSQL 的用户管理机制。我们将通过实际案例和代码演示，向你展示如何使用
psql
理解 PostgreSQL 中的“用户”与“角色”
在开始操作之前，我们需要先厘清一个核心概念：在 PostgreSQL 中，“用户”本质上就是一个“角色”。
从数据库系统的角度来看，用户是一个能够登录数据库并依据被授予的权限执行操作的实体。为了管理这些实体，PostgreSQL 引入了“角色”这一概念来统一管理权限。默认情况下，一个角色如果拥有 LOGIN 属性，它就可以被视为用户。这种设计非常灵活，允许我们在单一框架下管理用户组和单个用户。
为什么我们需要关注用户列表？
- 安全审计：我们需要定期审查谁拥有访问数据库的权限。很多时候，随着项目的人员变动，数据库中会积累大量“僵尸账号”，这些账号可能成为潜在的安全风险。
- 故障排查：当应用程序报错提示“权限拒绝”时，第一步就是检查连接用户是否存在，以及该用户是否具有特定 schema 或表的访问权限。
- 权限维护：了解当前用户及其角色成员关系，有助于我们更合理地规划角色的继承和权限的授予，避免权限过度开放。
方法一：使用 \du 命令快速查看
如果你正在使用 INLINECODEb9d05ba1 命令行界面（这是与 PostgreSQL 交互最直接的方式），那么查看用户列表最简单、最直观的方法就是使用 INLINECODE89a79a91 元命令。
\du 实际上是“display users”的缩写，它会直接查询系统目录并将结果以表格形式呈现。这个命令非常适合快速浏览，因为它不仅列出了用户名，还直观地展示了用户的关键属性。
#### 实际操作演示
让我们打开终端（或使用 DataGrip、DBeaver 等工具的 SQL 终端），连接到数据库后，直接输入以下命令：
\du
执行后，你将看到类似如下的输出结果：
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
admin | Create role, Create DB | {}
readonly | Cannot login | {analytics}
zhangsan | | {admin}
(4 rows)
#### 深度解读输出信息
从这个表格中，我们可以解读出非常丰富的信息，让我们逐列分析：
- Role name（角色名）：这是用户的登录名称。例如 INLINECODE564c1123 是默认的超级用户，INLINECODEdf472e7b 是我们创建的普通用户。
- Attributes（属性）：这一列非常关键，它定义了用户的能力。
* INLINECODE04b2a3f2：超级用户，拥有数据库的所有权限，可以绕过所有权限检查。通常只有 INLINECODE413eb851 应该拥有此权限。
* Create role：该用户可以创建新的角色（用户）。
* Create DB：该用户可以创建新的数据库。
* Replication：该用户可以用于数据流复制，常用于搭建主从架构。
* Bypass RLS：可以绕过行级安全策略（RLS）。
* Cannot login：这是一个非常重要的标志。如果出现这个属性，说明该角色不能被用来登录数据库，它通常是一个“组角色”，用于权限管理。
- Member of（成员归属）：这展示了角色的继承关系。例如 INLINECODE05f60750 是 INLINECODEf34d029d 组的成员，这意味着 INLINECODE51634caf 会自动继承 INLINECODE515bca42 角色的所有权限。
方法二：使用 SQL 查询 pg_roles 系统表
虽然
\du
- 我们正在编写一个自动化脚本来监控数据库状态。
- 我们需要从应用程序代码中查询用户列表。
- 我们需要根据特定条件（例如“查找所有拥有超级权限的用户”）进行过滤。
这时候，我们需要查询 PostgreSQL 的系统目录——
pg_roles
#### 基础查询：列出所有用户名
最基础的查询如下，这类似于
\du
-- 从系统角色视图中选择角色名称作为用户名
SELECT rolname AS username
FROM pg_roles;
输出示例：
username
-----------
postgres
admin
readonly
zhangsan
(4 rows)
#### 进阶查询：查看详细的权限配置
为了获得更接近 INLINECODEa91ca5bc 的详细信息，我们可以查询 INLINECODE31c31a8a 中的更多字段。PostgreSQL 将权限存储为“位图”标志，但我们可以通过系统函数将其转换为布尔值，以便更易读。
让我们来构建一个更有用的查询，它不仅显示用户名，还显示该用户是否是超级用户、是否可以创建数据库等：
SELECT
rolname AS username, -- 角色名称
rolsuper AS is_superuser, -- 是否为超级用户
rolcreaterole AS can_create_role, -- 是否可以创建角色
rolcreatedb AS can_create_db, -- 是否可以创建数据库
rolcanlogin AS can_login, -- 是否可以登录
rolreplication AS can_replicate, -- 是否可以进行复制
rolbypassrls AS bypass_rls -- 是否绕过行级安全
FROM
pg_roles
ORDER BY
rolname;
代码解析：
- 我们选择了多个布尔类型的字段（INLINECODE386b7fbe, INLINECODE9fccfba1 等），它们会返回 INLINECODE0e7af402 (true) 或 INLINECODE34f6a229 (false)。
- 使用
ORDER BY保证输出按字母顺序排列，便于查找。
输出示例：
username | is_superuser | can_create_role | can_create_db | can_login | can_replicate | bypass_rls
-----------+--------------+-----------------+---------------+-----------+---------------+------------
admin | f | t | t | t | f | f
postgres | t | t | t | t | t | t
readonly | f | f | f | f | f | f
zhangsan | f | f | f | t | f | f
(4 rows)
通过这个查询，我们可以一眼看出 INLINECODE3105c690 用户的 INLINECODE6964ea70 是 f，这解释了为什么应用使用该账号连接时会报错。
深入实战：常见的应用场景
仅仅知道如何列出用户是不够的，我们需要结合实际场景来发挥这些命令的作用。
#### 场景 1：排查“权限被拒绝”错误
假设你收到一个错误报告：“用户 INLINECODE14ad6f59 无法访问表 INLINECODEa945ab69”。
排查步骤：
首先，我们需要确认这个用户是否存在以及它是否能登录：
-- 检查用户是否存在及其登录状态
SELECT rolname, rolcanlogin
FROM pg_roles
WHERE rolname = ‘report_user‘;
如果结果显示为空，说明用户不存在，你需要创建它。如果 INLINECODE52409083 为 INLINECODEcad1bd20，则需要授予它登录权限：
-- 修改用户权限，允许登录
ALTER USER report_user WITH LOGIN;
接下来，你还需要检查该用户是否拥有连接到特定数据库的权限。这需要查询 INLINECODE9b9b118a 或数据库的 ACL（访问控制列表），但在 INLINECODEd037d512 中，我们可以使用 INLINECODE992d51ba 来查看数据库权限，或者更直接地使用 INLINECODE284f828b 确认用户所属的组。
#### 场景 2：清理不需要的用户（安全加固）
为了安全起见，定期扫描所有拥有“超级用户”权限的账号是一个好的习惯。默认情况下，我们应该只保留 postgres 作为超级用户。
查询超级用户：
-- 查找所有超级用户，排除默认的 postgres
SELECT rolname
FROM pg_roles
WHERE rolsuper = true
AND rolname != ‘postgres‘;
如果这个查询返回了任何结果，你应该仔细审查这些账号。如果它们是不必要的，应该考虑降级其权限：
-- 移除超级用户权限
ALTER USER unwanted_admin WITH NOSUPERUSER;
#### 场景 3：理解组角色和成员关系
在大型数据库中，最佳实践是使用“组角色”来管理权限，而不是直接给个人账号授权。例如，我们创建一个 INLINECODE00d720b1 组，并将 INLINECODEb7aa1304 权限授予该组，然后让所有只读用户加入这个组。
查看用户的成员关系：
虽然 INLINECODE18d3efb9 会显示 INLINECODEd3e3c228，但如果在 SQL 查询中，我们想要知道哪些用户属于特定的组，我们需要查询
pg_auth_members
-- 列出所有用户以及他们所属的组角色
SELECT
r.rolname AS username,
m.roleid AS group_role_oid, -- 组角色的 OID
r2.rolname AS group_role_name -- 组角色的名称
FROM
pg_auth_members m
JOIN
pg_roles r ON m.member = r.oid -- 关联成员角色
JOIN
pg_roles r2 ON m.roleid = r2.oid -- 关联组角色
ORDER BY
username, group_role_name;
这个查询能帮你清晰地梳理出“谁在哪个组”，这对于理解复杂的权限继承至关重要。
性能与最佳实践
在处理用户管理时，有几点经验和最佳实践值得分享：
- 使用组角色管理权限：不要把权限直接授予单个用户（如 INLINECODE1335b76d）。相反，应授予角色（如 INLINECODEc8a4c36f），然后将用户加入该角色。当新人加入或离职时，你只需要管理角色成员关系，而无需重新分配数百条表级权限。
- 避免过度使用超级用户：应用程序的连接字符串中绝对禁止包含
postgres超级用户信息。你应该创建具有特定权限的普通应用用户。
- 定期审计：建立一个自动化任务，定期导出
pg_roles
- 利用 INLINECODEbded10e1 的互交性：在紧急故障排查时，INLINECODE7c7e6ce0 和 INLINECODEdd5652f9（列出数据库）以及 INLINECODE07db789e（列出表权限）是你的最佳朋友。它们比编写复杂的 SQL 查询要快得多。
总结
在本文中，我们深入探讨了 PostgreSQL 中列出用户的多种方法。我们学习了：
- 概念：PostgreSQL 中的用户本质上就是拥有
LOGIN属性的角色。 - 工具使用：如何使用 INLINECODE0bdd0acd 的 INLINECODEa4e5ef80 命令快速概览用户及其关键属性。
- 底层原理：如何通过查询
pg_roles
- 实战应用：通过排查故障、清理超级用户、管理组成员关系的实际案例，巩固了查询技巧。
- 最佳实践：了解了使用组角色管理权限的重要性。
掌握这些技能，将帮助你更自信地管理数据库安全，确保只有正确的人拥有对数据的访问权限。下一次当你需要检查“谁连接了我的数据库”时，你就知道该怎么做了。希望你能在自己的环境中尝试这些命令，探索 PostgreSQL 强大的权限管理体系。