根本原因是缺少目标schema的usage权限，必须执行grant usage on schema schema_b to u1；该权限与表级select权限独立且缺一不可，且需高权限用户执行。
跨 schema JOIN 报 “permission denied for table” 怎么办
根本原因不是表没授权，而是用户缺少目标 schema 的 USAGE 权限。PostgreSQL 在解析 SQL 阶段就检查 schema 访问权，哪怕你只写 SELECT * FROM schema_b.t2，没 USAGE ON SCHEMA schema_b 就直接拒绝，连表是否存在都不查。
常见错误现象：
- 用
GRANT SELECT ON ALL TABLES IN SCHEMA schema_b TO u1授权后仍报错 - 能
\dt schema_b.*看到表名，但执行SELECT就失败 - Navicat 连接后看不到 schema_b 下的任何表（显示为空）
必须补上这句：
GRANT USAGE ON SCHEMA schema_b TO u1;
注意：这条命令和表级授权是独立的，缺一不可；且需由具有该 schema 所有权或 postgres 角色的用户执行。
如何让新创建的表自动继承查询权限
只授当前表权限，后续建的新表默认不继承——这是最常被忽略的“权限断层”点。尤其在定时任务、ETL 脚本或应用自动建表场景下，第二天就查不到数据。
解决方法是设置默认权限（ALTER DEFAULT PRIVILEGES），它影响的是“未来”对象：
ALTER DEFAULT PRIVILEGES IN SCHEMA schema_b GRANT SELECT ON TABLES TO u1;
关键细节：
- 这条语句只对执行者后续在
schema_b中创建的表生效，不影响已存在表 - 必须在建表前执行；如果已有表，仍需单独
GRANT SELECT ON ALL TABLES IN SCHEMA schema_b TO u1 - 不同用户需各自执行（或由 DBA 统一为常用角色设置）
- 不支持跨 schema 设置默认权限，比如不能在
schema_a里设schema_b的默认权限
用视图封装跨 schema 查询时权限怎么配
视图本身不绕过权限检查，而是“按定义者权限（SECURITY DEFINER）或调用者权限（SECURITY INVOKER）执行”。默认是 INVOKER，即调用者必须同时拥有视图中所有源表及其所在 schema 的完整访问权。
如果你希望普通用户查一个封装了 schema_a.users 和 schema_b.orders 的视图，但又不想开放两个 schema 的全部权限，可这样做：
- 用高权限用户（如
admin）创建视图，并显式声明CREATE VIEW v_user_orders AS ... SECURITY DEFINER - 确保该用户对
schema_a和schema_b都有USAGE+ 表级SELECT权限 - 给目标用户只授
SELECT权限在视图上：GRANT SELECT ON v_user_orders TO u1
注意：SECURITY DEFINER 视图会以定义者身份执行，因此调用者无需再有底层表权限——但这也意味着你要严格控制谁可以创建这类视图，避免权限越界。
为什么加了权限 Navicat 还不显示表
Navicat 缓存 schema 元数据非常顽固，权限变更后不会自动刷新。它看到的“空 schema”其实是本地缓存，不是数据库真实状态。
强制刷新步骤：
- 右键连接名 → 选“刷新”（不是按 F5，也不是刷新查询窗口）
- 若仍无效，断开连接再重连（部分版本如 Navicat 15.x 对
ALTER DEFAULT PRIVILEGES延迟明显，建议升到 16.2+） - 验证是否真生效：在 SQL 窗口执行
SELECT has_schema_privilege('u1', 'schema_b', 'USAGE');，返回t才算成功
真正容易被忽略的是：权限配置只是前提，工具端感知不到变更才是实际卡点。别在命令行验证完就以为万事大吉，务必在客户端完成一次真实刷新动作。
