真正有效的视图防护是严格管控schema的CREATE权限，而非依赖视图专属DDL开关；在PostgreSQL和Hologres中，只要用户对schema拥有CREATE权限，即可CREATE OR REPLACE VIEW覆盖原视图，因此必须REVOKE CREATE ON SCHEMA并确保视图owner为专用角色。
直接给视图加锁或限制修改权限，不是靠“禁止 ALTER VIEW”这种操作实现的——PostgreSQL 和 Hologres 等主流系统根本不提供对单个视图的独立 DDL 权限开关。真正有效的做法，是切断用户执行 ALTER VIEW 所依赖的底层权限链。
为什么 GRANT SELECT 不足以保护视图不被修改
很多人误以为只要没给 CREATE 或 USAGE 权限，用户就动不了视图。但实际中：
-
ALTER VIEW的前提是用户是该视图的 owner，或者拥有整个 schema 的CREATE权限（在 PostgreSQL 中，CREATEon schema 允许重命名、替换视图） - Hologres 的简单权限模型（SLPM）下，若用户对 schema 有
USAGE+CREATE，就能CREATE OR REPLACE VIEW，哪怕原视图属于别人 - 即使视图定义里引用了多 schema 表，在 SLPM 模式下，只要用户对当前 schema 有
CREATE，仍可覆盖——跨 schema 引用只影响查询执行时的权限校验，不影响 DDL
PostgreSQL 中阻断视图修改的关键授权组合
核心思路：让非 owner 用户既不能成为新 owner，也无法替换对象。需同时控制 schema 级和对象级权限：
- 对目标 schema，只授予
USAGE，**绝对不要给CREATE**：REVOKE CREATE ON SCHEMA report FROM analyst;
- 确保视图 owner 是专用角色（如
view_admin），且该角色不开放给普通用户登录 - 若需允许用户“基于视图查数据”，只需：
GRANT SELECT ON view_sales_summary TO analyst;
- 避免使用
GRANT ALL PRIVILEGES ON SCHEMA ...——它隐含CREATE，等同于开门揖盗
Hologres SLPM 模式下视图防护的特殊约束
SLPM（Schema-Level Permission Model）强制按 schema 隔离，但它对 DDL 的控制更粗粒度，容易踩坑：
- 一旦用户对某个 schema 有
CREATE权限，他就可CREATE OR REPLACE VIEW同名视图，覆盖原定义——哪怕原视图由其他用户创建 - 跨 schema 视图（如
SELECT * FROM public.users JOIN finance.payments）在 SLPM 下会直接报错permission denied for schema finance，除非用户对两个 schema 都有USAGE，但此时他同样可能覆盖public下的视图 - 正确做法是：为视图单独建一个只读 schema（如
v_readonly），仅授USAGE，所有视图由 admin 在此 schema 创建并设 owner，再GRANT SELECT给业务角色
最容易被忽略的破坏点：角色继承与默认权限
即使你手动 revoke 了 CREATE，权限仍可能悄悄回来：
- 用户所属的 role 可能继承了其他 role 的
CREATE权限（用\du+查看Member of列） - schema 上设置了
ALTER DEFAULT PRIVILEGES，导致后续新建视图自动赋予不该有的权限 - PostgreSQL 中，
publicschema 默认对所有用户有CREATE（9.6+ 已改，但老实例或自定义 template 可能仍保留）——务必检查：SELECT nspname, pg_get_userbyid(nspowner), has_schema_privilege(nspname, 'CREATE') FROM pg_namespace WHERE nspname = 'public';
真正的防护不在视图本身，而在 schema 的 CREATE 权限是否被严格收口；任何绕过 schema 级管控的“视图专属权限”都是幻觉。
