根本原因是PostgreSQL查询视图时会递归检查其定义中所有基表的权限，仅授予视图SELECT权限不足以访问，必须为视图依赖的每张基表单独授权SELECT权限。
为什么对视图有SELECT权限却报“permission denied for table”？
根本原因不是视图本身没权限，而是PostgreSQL在查询视图时会**递归检查视图定义中所有基表的权限**。即使你已经给用户授予了SELECT ON view_name，只要视图里引用的某张表（比如user1.test_t2）对该用户没有SELECT权限，执行SELECT * FROM user1.test_v2就会失败。
典型错误信息：ERROR: permission denied for table test_t2 —— 注意它指向的是基表，不是视图名。
- 视图权限是“代理式”的：用户查视图，等价于以该用户身份去查背后的SQL（含JOIN、子查询等）
-
GRANT SELECT ON view_name只控制访问视图入口，不豁免底层对象权限 - 哪怕视图只SELECT一张表，这张表也必须单独授权
如何正确授予视图及所有依赖对象的权限？
不能只授视图，必须覆盖其定义中显式引用的所有表、视图、序列等。最稳妥的做法是：先确认视图依赖关系，再批量授权。
查视图依赖：
SELECT DISTINCT n.nspname AS schema_name, c.relname AS rel_name, c.relkind FROM pg_depend d JOIN pg_class c ON d.refobjid = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid WHERE d.objid = 'user1.test_v2'::regclass;
结果会列出test_t1和test_t2（类型为r表示表）。然后分别授权：
GRANT SELECT ON TABLE user1.test_t1 TO user2;GRANT SELECT ON TABLE user1.test_t2 TO user2;GRANT SELECT ON VIEW user1.test_v2 TO user2;
注意：GRANT SELECT ON ALL TABLES IN SCHEMA user1 TO user2能覆盖所有表，但对后续新建的表无效——除非配合ALTER DEFAULT PRIVILEGES。
为什么ALTER DEFAULT PRIVILEGES对视图不起作用？
这是个高频误解。ALTER DEFAULT PRIVILEGES IN SCHEMA user1 GRANT SELECT ON TABLES TO user2只影响**未来创建的表**，不影响视图，也不影响视图里引用的对象。
视图属于VIEW类型，而DEFAULT PRIVILEGES默认只对TABLES、SEQUENCES、FUNCTIONS生效，不包含VIEWS。想让新视图自动带权限，必须显式加上：
ALTER DEFAULT PRIVILEGES IN SCHEMA user1 GRANT SELECT ON VIEWS TO user2;
- 该命令仅对
user1下之后创建的视图生效，已有视图仍需手动GRANT - 若视图引用其他schema的表，还需在对应schema上设置
DEFAULT PRIVILEGES或单独授权 - 别漏掉
USAGE权限：用户必须对user1schema有USAGE才能看到其中对象
用SECURITY DEFINER视图绕过基表权限检查？
可以，但要极度谨慎。创建带SECURITY DEFINER属性的视图后，查询时会以视图所有者（如user1）身份检查权限，而不是调用者（user2）。
CREATE OR REPLACE VIEW user1.test_v2_secure AS SELECT * FROM user1.test_t1 JOIN user1.test_t2 USING (id) WITH LOCAL CHECK OPTION; ALTER VIEW user1.test_v2_secure OWNER TO user1; -- 必须显式设置 ALTER VIEW user1.test_v2_secure SECURITY DEFINER;
- 调用者只需对视图有
SELECT权限，无需基表权限 - 风险极高：视图所有者权限被滥用，可能泄露敏感数据或触发越权操作
- 生产环境禁用，除非严格审计视图SQL且所有者为受信角色
- 记得回收视图所有者的高危权限（如
CREATEROLE、SUPERUSER）
真正容易被忽略的点是：视图权限问题从来不是孤立的，它永远牵扯到至少两层对象（视图 + 基表），而错误提示却只暴露最底层那个缺失权限的对象。排查时必须顺着\d+ view_name和pg_depend往回挖，不能停留在报错表面。
