PostgreSQL提供了一组预定义角色，它们提供对特定的、通常需要的、需要特权的功能和信息的访问。
管理员(包括具有CREATEROLE 权限的角色)可以把这些角色GRANT给其环境中的用户或者其他角色，让这些用户能够访问指定的功能和信息。
表 22.1中描述了预定义的角色。 注意由于额外功能的增加，每一种角色相关的权限可能会在未来被改变。 管理员应该关注发行注记中提到的这方面的变化。
表 22.1. 预定义角色
| 角色 | 允许的访问 |
|---|---|
| pg_read_all_data | 读所有数据(表，视图，序列), 如同在那些对象上有 SELECT 权限，在所有模式上有USAGE权限，即使没有显式拥有它。
这个角色没有角色属性BYPASSRLS集。
如果使用了RLS，管理员可能希望设置角色上的被GRANTed给该角色的BYPASSRLS。 |
| pg_write_all_data | 写全部数据(表，视图，序列)， 如果在那些对象上有INSERT、UPDATE和DELETE权限，以及在全部模式上有USAGE权限，即使没有显式拥有它。
这个角色没有角色属性BYPASSRLS 集。
如果使用了RLS，管理员可能希望设置角色上的被GRANTed给该角色的BYPASSRLS。 |
| pg_read_all_settings | 读取所有配置变量，甚至是那些通常只对超级用户可见的变量。 |
| pg_read_all_stats | 读取所有的pg_stat_*视图并且使用与扩展相关的各种统计信息，甚至是那些通常只对超级用户可见的信息。 |
| pg_stat_scan_tables | 执行可能会在表上取得ACCESS SHARE锁的监控函数（可能会持锁很长时间）。 |
| pg_monitor | 读取/执行各种不同的监控视图和函数。
这角色是pg_read_all_settings，pg_read_all_stats和pg_stat_scan_tables的成员。 |
| pg_database_owner | 无. 成员构成，隐式的，当前数据库的所有者。 |
| pg_signal_backend | 发信号到其他后端以取消查询或中止它的会话。 |
| pg_read_server_files | 允许使用COPY以及其他文件访问函数从服务器上该数据库可访问的任意位置读取文件。 |
| pg_write_server_files | 允许使用COPY以及其他文件访问函数在服务器上该数据库可访问的任意位置中写入文件。 |
| pg_execute_server_program | 允许用运行该数据库的用户执行数据库服务器上的程序来配合COPY和其他允许执行服务器端程序的函数。 |
pg_monitor、pg_read_all_settings、pg_read_all_stats和pg_stat_scan_tables角色的目的是允许管理员能为监控数据库服务器的目的很容易地配置角色。它们授予一组常用的特权，这些特权允许角色读取各种有用的配置设置、统计信息以及通常仅限于超级用户的其他系统信息。
pg_database_owner 角色有一个隐式，情况依赖的成员，也就是当前数据库的所有者。
该角色开始没有传递任何特权。
就像任何角色一样，它可以拥有对象或者接受访问权限的授予。
因此，当pg_database_owner有模板数据库的权限，从该模板实例化的数据库的每个所有者都将运用这些权限。
pg_database_owner不能成为任何角色的成员，并且它不能有非隐式成员。
pg_signal_backend角色想要允许管理员启用受信任的、但是非超级用户的、发送信号给其他后端的角色。
当前，此角色允许发送信号以取消另一个后端上的查询或终止其会话。不过授予此角色的用户不能向属于超级用户的后端发送信号。
参见第 9.27.2 节
pg_read_server_files、pg_write_server_files以及pg_execute_server_program角色的目的是允许管理员有一些可信但不是超级用户的角色来访问文件以及以运行数据库的用户在数据库服务器上运行程序。
由于这些角色能够访问服务器文件系统上的任何文件，因此在直接访问文件时它们会绕过任何数据库级别的权限检查并且它们可以被用来得到超级用户级别的访问，因此在把这些角色授予给用户时应当特别小心。
在授予这些角色时应当非常小心，以确保它们只被用在需要的地方，并且要理解这些角色会授予对特权信息的访问。
管理员可以用GRANT命令把对这些角色的访问授予给用户，例如：
GRANT pg_signal_backend TO admin_user;