navicat提示“no schema has been selected”或“permission denied for schema public”是连接成功后因用户缺乏public schema的usage权限所致，需执行grant usage on schema public to username，并刷新连接或重连以生效。
navicat提示“no schema has been selected”或“permission denied for schema public”
这不是连接失败，而是连接成功后执行查询时被拦在了schema层——postgresql默认不自动赋予新用户对public schema的usage和select权限。即使你用postgres用户连上了，如果目标数据库是新建的、且用户没显式授权，navicat在展开表列表或执行select * from users时就会报这个错。
确认当前用户对schema的实际权限
先别急着GRANT，用psql或Navicat自带的SQL窗口查清楚现状：
SELECT nspname, pg_get_userbyid(nspowner) AS owner FROM pg_namespace WHERE nspname NOT LIKE 'pg_%' AND nspname != 'information_schema';
再查用户权限：
SELECT nspname, has_schema_privilege('your_username', nspname, 'USAGE') AS can_use,
has_schema_privilege('your_username', nspname, 'CREATE') AS can_create
FROM pg_namespace
WHERE nspname = 'public';
如果can_use返回false，就坐实了权限缺失。
用GRANT给用户加schema权限（不是数据库权限）
注意：schema权限和数据库权限是两层事。GRANT CONNECT ON DATABASE只管能不能连库，不管能不能查表；真正控制“看不看得见表、能不能建表”的是schema级权限。
-
GRANT USAGE ON SCHEMA public TO your_username;—— 必须加，否则Navicat连schema都进不去，看不到任何表 -
GRANT SELECT ON ALL TABLES IN SCHEMA public TO your_username;—— 让已有表可读（但对后续新建表无效） -
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO your_username;—— 关键！让之后新建的表也自动继承SELECT权限
如果你要写入，把SELECT换成INSERT, UPDATE, DELETE，但别直接GRANT ALL，生产环境慎用。
为什么改了权限Navicat还是不刷新？
Navicat缓存schema结构很顽固，尤其在连接复用场景下：
- 右键连接名 → “刷新”（不是F5），强制重载schema元数据
- 如果仍不显示表，尝试断开连接再重连——它不会自动感知权限变更
- 某些老版本Navicat（如15.x）对
ALTER DEFAULT PRIVILEGES生效延迟明显，升级到16.2+更稳
最易忽略的一点：public不是唯一schema，如果你在Navicat里手动切换到了其他schema（比如app_data），那上面所有操作都得针对那个schema重做一遍——权限不跨schema自动继承。
