必须授予用户对schema的create和usage权限，以及基表的select权限；刷新物化视图还需是其owner，create权限不赋予ownership。
必须先有 create materialized view 权限，且所在 schema 有 usage 权限，否则直接报错 permission denied for schema public 或 must be owner of relation。
授予用户创建物化视图的最小权限集
PostgreSQL 不提供单独的 CREATE MATERIALIZED VIEW 系统权限，它隐式绑定在 schema 的 CREATE 权限上。也就是说：给用户对某个 schema 的 CREATE 权限，就等于允许其在该 schema 下建物化视图（前提还满足其他依赖权限）。
-
GRANT CREATE ON SCHEMA public TO alice;—— 允许在public下建物化视图（以及表、函数等） -
GRANT USAGE ON SCHEMA public TO alice;—— 必须同时给USAGE，否则连 schema 都不可见，会报permission denied for schema public - 如果物化视图基于某张基表（比如
sales），用户还需对该基表有SELECT权限：GRANT SELECT ON sales TO alice;
为什么只给 CREATE 还是报 must be owner of relation
这个错误通常不是权限不够，而是你试图刷新（REFRESH MATERIALIZED VIEW）或删除一个别人创建的物化视图。PostgreSQL 要求：只有物化视图的 owner 才能执行 REFRESH、DROP、ALTER OWNER 等操作 —— CREATE 权限不等于 ownership。
- 新建物化视图时，owner 自动设为执行
CREATE的用户，和 schema owner 无关 - 若需让多个用户都能刷新同一物化视图，只能把 owner 改成一个共享角色（如
mv_admin），再让各用户SET ROLE mv_admin后操作 - 不能靠
GRANT把“刷新权”拆出来 —— 它没有对应权限项
用 CREATE MATERIALIZED VIEW 建视图时容易漏的依赖权限
物化视图本质是物理存储的查询结果，它的创建过程会“预执行”一次查询，所以所有被引用对象的访问权限都得当场校验。
- 如果查询里用了函数（如
get_monthly_report()），用户需有该函数的EXECUTE权限 - 如果查询跨 schema（如
analytics.users），除了SELECT，还得确保对analyticsschema 有USAGE - 如果基表上有行级安全策略（RLS），且当前用户不是 owner 或 bypassrls 角色，
CREATE MATERIALIZED VIEW会直接失败 —— RLS 在创建阶段就生效
最常被忽略的是：物化视图的 owner 和刷新者必须一致，而权限和 owner 是两回事；很多人以为给了 CREATE 就能随便刷，结果卡在 REFRESH 上。别绕开 owner 去设计自动化刷新逻辑，要么统一用一个专用角色操作，要么用 SECURITY DEFINER 函数封装刷新动作。
