用select *建视图会埋雷，因它固化查询逻辑而非快照，底层表结构变更会导致列序、数量、类型突变，引发字段不存在或数据错位；必须显式列名并一一对应、加as别名，join和表达式尤需去重命名，临时调试外无例外。
为什么 CREATE VIEW 里用 * 会埋雷？
因为视图定义固化的是查询逻辑，不是快照；一旦底层表加/删/重排字段，SELECT * 视图的列顺序、数量甚至类型都可能突变，而调用方完全不知情。
常见错误现象：ERROR: column "xxx" does not exist 或数据错位（比如把 updated_at 当成 created_at 读），尤其在应用层做了字段硬编码或 ORM 映射时，崩溃往往发生在上线后。
- PostgreSQL 不会在创建视图时展开
*—— 它只是原样存下该字符串，执行时才动态解析底层表结构 - 即使底层表只新增一列，视图返回的列数就 +1，所有依赖列序的代码（如
SELECT v.* FROM my_view v LIMIT 1后按位置取值）立刻失效 -
pg_dump备份还原时，若先建视图再建表，*视图会因依赖未就绪而创建失败（报relation does not exist）
CREATE VIEW 显式列名怎么写才安全？
核心原则：和底层 SELECT 的实际输出列严格一一对应，且每列必须有明确别名（尤其涉及表达式、函数、JOIN 冗余字段时）。
实操建议：
- 不要省略别名：即使列名和源字段一致，也显式写
id AS id，避免未来源字段改名导致视图失效 - JOIN 场景必须去重：两个表都有
id，必须写成t1.id AS user_id, t2.id AS order_id，否则CREATE VIEW直接报错 - 表达式必须命名：
COALESCE(status, 'unknown') AS status，不写AS就没列名，视图无法被下游引用 - 避免用序号引用：
SELECT a,b,c FROM t定义的视图，后续绝不能写SELECT col2 FROM v（PostgreSQL 不支持按位置取列）
已有星号视图怎么补救？
不能直接 ALTER VIEW ... SET ... 改列定义，必须重建。但重建有风险，得先确认依赖关系。
步骤建议：
- 查依赖：
SELECT dependent_ns.nspname, dependent_view.relname FROM pg_depend JOIN pg_rewrite ON pg_depend.objid = pg_rewrite.oid JOIN pg_class AS dependent_view ON pg_rewrite.ev_class = dependent_view.oid JOIN pg_namespace AS dependent_ns ON dependent_view.relnamespace = dependent_ns.oid WHERE refobjid = 'old_view'::regclass; - 导出现有定义：
pg_get_viewdef('old_view')拿到原始 SQL，手动替换*为当前实际列（可用\d+ old_view查结构） - 用
CREATE OR REPLACE VIEW重建 —— 注意：这会中断正在执行的查询，生产环境建议选低峰期 - 重建后立刻验证：
SELECT * FROM new_view LIMIT 1看列名/类型是否符合预期，再跑关键业务 SQL
有没有例外情况可以接受 *？
几乎没有。唯一勉强算例外的是临时调试用的 psql 会话内 CREATE TEMP VIEW，生命周期短、无外部依赖、且你随时能重写。
但只要视图进入迁移脚本、CI/CD 流程或被任何其他对象（函数、物化视图、另一视图）引用，就必须显式列名。
容易被忽略的一点：视图列名还影响统计信息收集 —— PostgreSQL 的 pg_stats 对 * 视图不生成列级统计，导致 JOIN 或过滤时执行计划失准，性能问题会延迟暴露。
