必须通过数据库执行GRANT语句授权，DBeaver界面仅支持查看权限而非修改；需先GRANT USAGE ON SCHEMA，再GRANT SELECT ON VIEW，否则权限不生效。
直接给用户开放只读视图，不是在 DBeaver 里“授权”，而是通过数据库本身执行 GRANT 语句赋予 SELECT 权限；DBeaver 只是执行这条语句的客户端工具。如果你跳过这步、只在 DBeaver 界面里点点点，权限不会生效。
为什么不能在 DBeaver 界面里点出只读视图权限
DBeaver 的对象浏览器（比如右键视图 → “编辑权限”）对多数数据库（PostgreSQL、RisingWave、openGauss 等兼容 PostgreSQL 协议的库）仅支持查看当前权限，不支持写入修改。它底层调用的是 pg_catalog 或 information_schema 的只读元数据查询，没有触发 GRANT 的实际执行逻辑。
常见错误现象：
- 右键视图 → “编辑权限” → 勾选 “SELECT” → 点确定，但新用户仍报
permission denied for view xxx - 连接用户本身没有
USAGE ON SCHEMA，导致连 schema 都看不到，更别说视图
正确做法：用 SQL 显式授予 SELECT 权限
在 DBeaver 的 SQL 编辑器中运行以下语句（以 PostgreSQL/RisingWave/openGauss 为例）：
GRANT USAGE ON SCHEMA public TO dbeaver_user; GRANT SELECT ON VIEW user_summary TO dbeaver_user;
关键点说明：
-
USAGE ON SCHEMA是前提：没有它，用户连public这个 schema 都不可见，视图名都补全不出来 -
SELECT ON VIEW是核心：只给视图本身权限，不涉及底层基表（只要视图定义者有权限，且未使用SECURITY DEFINER） - 若视图依赖多个 schema 下的对象，需逐个
GRANT USAGE，否则运行时仍可能报错 - 不要用
GRANT SELECT ON ALL TABLES IN SCHEMA替代 —— 它不作用于视图，只管表
验证权限是否生效的三步检查法
换一个以目标用户身份新建的 DBeaver 连接，执行以下检查：
- 执行
SELECT current_user;确认登录用户是dbeaver_user - 执行
SELECT * FROM information_schema.role_table_grants WHERE table_name = 'user_summary';查看该视图是否有对应SELECT记录 - 直接运行
SELECT * FROM user_summary LIMIT 1;—— 成功返回结果才代表真正可用
容易被忽略的是 schema 级别的 USAGE 权限，它不像表权限那么直观，但缺失时整个视图路径就断了。很多“明明授了权却查不了”的问题，根源都在这一行漏掉的 GRANT USAGE 上。
