会重置权限，因为create or replace view本质是隐式drop再重建，新视图拥有全新oid，原视图上的所有grant记录全部失效，必须手动重新执行grant语句。
CREATE OR REPLACE VIEW 会重置权限吗？
不会自动重置，但会丢失显式授予的 GRANT 权限——因为 PostgreSQL 在执行 CREATE OR REPLACE VIEW 时，本质是先隐式 DROP 再重建，新视图对象拥有全新 OID，原视图上的所有 GRANT 记录（存在 pg_class 的 relacl 字段里）全部失效。
常见错误现象：
用户之前能 SELECT 视图，替换后报 permission denied for view xxx；
或视图被多个角色依赖，只给其中一个重授了权限，其他角色突然无法访问。
- 必须在
CREATE OR REPLACE VIEW后，重新执行所有GRANT语句（哪怕只是复制粘贴一遍） - 如果用脚本管理权限，建议把
GRANT语句和视图定义放在同一部署单元里，避免漏执行 - 注意：角色继承关系不受影响，但直接授予该视图的权限必须重做
为什么不能用 ALTER VIEW 修改查询逻辑？
ALTER VIEW 在 PostgreSQL 中不支持修改 AS SELECT ... 部分——它只能改视图的“次要属性”，比如所有者（OWNER TO）、模式（SET SCHEMA）、列默认值（ALTER COLUMN ... SET DEFAULT），或者加/删 WITH CHECK OPTION。试图用它改查询体，会直接报错：ERROR: syntax error at or near "AS"。
所以你看到的 ALTER VIEW xxx AS SELECT ... 是无效语法，PostgreSQL 不认。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 真正等价于“修改逻辑”的操作只有
CREATE OR REPLACE VIEW或DROP VIEW+CREATE VIEW - 不要被 SQL Server 的
ALTER VIEW行为误导——PostgreSQL 没有该能力 - 若视图定义很长，建议用
\e在 psql 里编辑，避免手敲出错
如何安全替换视图并保留权限一致性？
最稳妥的做法不是“绕过权限丢失”，而是主动控制权限生命周期。核心思路：把权限当作视图定义的一部分来版本化。
- 每次修改视图前，先用
pg_dump --schema-only --no-owner --no-privileges导出当前结构（不含权限），再用--no-tablespaces --no-unlogged-table-data等参数补全权限语句 - 或者用元数据查询生成授权语句：
SELECT 'GRANT ' || privilege_type || ' ON VIEW ' || viewname || ' TO ' || grantee || ';' FROM pg_views v JOIN pg_catalog.pg_class c ON c.relname = v.viewname JOIN pg_catalog.aclexplode(c.relacl) a ON true WHERE c.relkind = 'v' AND v.schemaname = 'public';
- 生产环境强烈建议用部署脚本封装：先备份权限 → 替换视图 → 重授权限 → 验证
SELECT是否成功
字段变更时容易踩的坑
CREATE OR REPLACE VIEW 允许在末尾追加新列，但禁止删列、改列名、调序——否则报错：ERROR: cannot drop columns from view 或 cannot change name of view column。这不是权限问题，而是 PostgreSQL 的元数据兼容性限制。
例如原视图返回 (id, name)，新定义写成 SELECT id, email, name FROM t 就失败，因为 email 插在中间；但写成 SELECT id, name, email FROM t 可以。
- 如果必须删列或重排，只能走
DROP VIEW+CREATE VIEW流程，并确保下游应用已适配新列序 - BI 工具或 ORM 常按位置取字段（如
row[0]），列序变动可能引发静默数据错位 - 视图被其他视图引用时（A → B → C），改 B 必须先删 C 再删 B，否则
DROP VIEW B CASCADE会连带删掉 C，而CREATE OR REPLACE不处理依赖链
