Chris van Eijk：PostgreSQL 中“permission denied for table”报错：究竟缺少哪项授权？
内容提要
本文实测 PostgreSQL 17 中“permission denied for table”错误：该报错仅提示缺少权限，不指明具体权限和角色。写入语句常需额外 SELECT 权限，如 RETURNING、WHERE、冲突目标等；序列、视图、函数、行级安全策略子查询也会触发此错。默认权限仅对特定角色新建对象生效，迁移后新表常被拒。可用 has_table_privilege 等函数排查缺失授权。
延伸解读
写操作为何需要 SELECT 权限
文章实测表明，UPDATE、DELETE、INSERT 等写语句在引用列值时需要额外的 SELECT 权限。例如 UPDATE ... WHERE 条件、RETURNING 子句、ON CONFLICT 冲突目标都会读取列，因此仅授予写权限不够。许多 ORM 默认发送 INSERT ... RETURNING id，若角色只有 INSERT 权限，就会触发 permission denied for table。这提醒我们，权限规划不能只看语句类型，还要考虑语句是否隐式读取数据。
默认权限为何在迁移后失效
ALTER DEFAULT PRIVILEGES 只对特定角色创建的对象生效，未指定 FOR ROLE 时仅影响执行该语句的角色。若迁移由 migrator 角色执行，而默认权限是为 postgres 设置的，新表就不会自动授权。此外，GRANT ON ALL TABLES 只覆盖执行时已存在的表。因此，迁移后新表常出现权限拒绝，需要确保默认权限针对正确的创建角色，或在新表创建后显式授权。
视图、函数与策略如何引发意外报错
当查询涉及 security_invoker 视图、普通函数或行级安全策略中的子查询时，错误可能指向查询未直接引用的表。因为这些对象以调用者权限读取底层表，若调用者缺少相应 SELECT 权限，就会报 permission denied for table。解决方法是授予底层表权限，或将逻辑封装在 SECURITY DEFINER 函数中，但后者需注意固定 search_path 并撤销 PUBLIC 的 EXECUTE 权限。
排查缺失授权的实用方法
文章推荐使用 has_table_privilege、has_schema_privilege 等函数以超级用户或所有者身份检查特定角色的权限。通过查询 pg_class 和 pg_namespace 可以列出模式中权限不足的表，并显示所有者以区分原因。psql 的 \dp 和 \ddp 命令也能直观显示表权限和默认权限。这些工具能帮助快速定位缺失的授权，避免盲目尝试。
Q&A
PostgreSQL 报错 permission denied for table 到底是什么意思？
表示执行语句的角色缺少该语句所需的表权限。权限检查在语句开始时进行，与表内容无关。错误只提示缺少权限，不指明具体权限和角色。
为什么 UPDATE 语句已经授予了 UPDATE 权限，还是报 permission denied for table？
因为写操作如果读取了列值（如 WHERE、RETURNING、冲突目标或 amount = amount + 1），还需要 SELECT 权限。文档指出：引用现有列值时需要 SELECT 权限。
迁移后新建的表为什么应用角色没有权限？
GRANT ON ALL TABLES 只覆盖执行时已存在的表；ALTER DEFAULT PRIVILEGES 只对特定角色（默认是执行该语句的角色）创建的对象生效。若迁移角色与执行默认权限的角色不同，新表不会被授权。
如何排查具体缺少哪个授权？
使用 has_table_privilege、has_schema_privilege、has_sequence_privilege 等函数，以被拒角色为第一参数查询。也可用查询列出 schema 中缺少权限的表及其所有者。
permission denied for table 是行级安全策略导致的吗？
通常不是。行级安全策略隐藏行时返回零行或抛出其他错误（如 new row violates row-level security policy）。唯一例外是策略中包含子查询读取另一张表时，会因缺少该表的权限而报此错。
为什么错误提示的表在查询中根本没出现？
因为视图、函数或行级安全策略中的子查询读取了该表，且这些读取以调用者权限执行。例如 security_invoker 视图、普通 SQL 函数、策略子查询都会导致错误指向底层表。
