视图无法添加主键约束或唯一索引，因其仅为查询定义、无物理存储和行标识；PostgreSQL在DDL解析阶段即拒绝ALTER VIEW ADD CONSTRAINT，且CREATE UNIQUE INDEX ON视图会报“is not a table”错误。
视图上执行 ALTER VIEW ... ADD CONSTRAINT PRIMARY KEY 会直接报错
数据库在 DDL 解析阶段就拒绝该语法。视图对象类型（pg_class.relkind = 'v'）和基表（'r'）完全不同，系统根本不允许在其上注册约束。你哪怕写 CREATE OR REPLACE VIEW v AS SELECT id FROM t WHERE id > 0 PRIMARY KEY (id)，解析器也会忽略 PRIMARY KEY 部分——它不是语法错误，而是被静默丢弃，不入库、不生效、不报错（但也不起作用）。
为什么 CREATE UNIQUE INDEX ON my_view(...) 同样失败
唯一索引必须建在物理可寻址的表上，而视图没有存储、没有行标识、无法加锁。PostgreSQL 报 ERROR: "my_view" is not a table，SQL Server 报 Invalid object name 'my_view'，MySQL 则直接提示 Unknown table 'my_view'。根本原因：索引依赖底层数据页和行偏移，视图只是查询文本，引擎连“在哪存”都不知道，更谈不上构建 B-tree 结构。
即使视图结果恰好唯一，数据库也完全不承认
- 视图定义可能含
JOIN、GROUP BY、UNION或聚合函数，结果集连函数依赖都不满足，唯一性无从谈起 - 即使你用
SELECT DISTINCT id FROM users建视图，DBMS 仍视其为不可靠逻辑层——源表增删改后，视图结果实时变化，但约束无法动态重校验 -
INFORMATION_SCHEMA.TABLE_CONSTRAINTS和sys.key_constraints这类元数据视图里，永远查不到视图名对应的主键记录
想让“视图逻辑”具备主键语义，只能下沉到基表
真正可行的路径不是在视图上硬加约束，而是把筛选/组合逻辑前移到基表设计层：
- 如果视图是
SELECT * FROM users WHERE status = 'active'，就在users表上确保id是主键，并用CHECK (status IN ('active', 'inactive'))或应用层校验来补充业务规则 - 如果视图是多表关联结果（如用户+配置），外键应指向主实体表（如
users.id），其余字段通过JOIN获取，而非试图让视图本身承担主键职责 - 物化视图（如 PostgreSQL 的
MATERIALIZED VIEW）虽有物理存储，但仍不能直接ADD PRIMARY KEY—— 它缺少约束注册入口，必须先CREATE TABLE AS SELECT ...再手动加主键
最易被忽略的一点：数据库认的是元数据里的对象类型，不是名字。哪怕你把视图命名为 users_pk，它依然是 relkind = 'v'，引擎不会为它启动任何约束校验流程。
