PostgreSQL中ON CONFLICT报“no unique or exclusion constraint matching”错误，是因为conflict_target必须精确匹配表上已存在的B-tree唯一索引或主键，顺序、列名、约束类型缺一不可；DO UPDATE中禁止子查询、聚合及窗口函数，属内核级执行阶段限制。
PostgreSQL 存储过程中能直接用 INSERT ... ON CONFLICT，但必须确保表有对应唯一约束，且不能在 DO UPDATE 中写子查询或聚合函数——否则运行时报错，不是语法高亮问题，是内核级限制。
为什么存储过程里写 INSERT ... ON CONFLICT 会报 “no unique or exclusion constraint matching”？
这不是存储过程特有的问题，而是所有上下文共有的前提条件：PostgreSQL 要求 ON CONFLICT 指定的 conflict_target 必须精确匹配一个已存在的唯一索引（UNIQUE）或主键（PRIMARY KEY），且该索引必须由 B-tree 实现（不支持哈希索引或部分索引作为冲突目标）。
常见踩坑点：
- 建表时只加了
UNIQUE约束，但没确认是否自动创建了索引（其实会，但需注意命名和顺序） - 用了多列组合，但
ON CONFLICT (a, b)和实际索引定义顺序不一致（例如索引是ON tab(b, a)，就不能这么写） - 在存储过程中动态拼接 SQL 字符串，却把列名当变量传入，导致
conflict_target解析失败（PostgreSQL 不允许变量化冲突目标）
DO UPDATE SET 在存储过程中有哪些硬性限制？
这些限制在普通 SQL 里也存在，但在存储过程中更容易被忽略，因为逻辑变长、调试变难：
-
EXCLUDED只能在SET和WHERE子句中引用，不能出现在子查询里（比如SET x = (SELECT MAX(y) FROM t WHERE id = EXCLUDED.id)是非法的） - 不能更新分布键或主键列（某些云厂商如 Hologres 或 AnalyticDB for PostgreSQL 显式禁止）
-
WHERE条件里不能用聚合函数、窗口函数，也不能嵌套SELECT—— 这类表达式在冲突处理阶段尚未进入完整查询计划阶段 - 想“仅当新值非 NULL 才更新”，得用
COALESCE(EXCLUDED.col, target_table.col)，而不是依赖触发器或额外IF判断
如何在存储过程中安全地复用 INSERT ... ON CONFLICT 逻辑？
避免把整个语句写成字符串拼接（易 SQL 注入、难调试），推荐用参数化方式封装，但注意：冲突目标不能参数化，只能硬编码。
示例（PL/pgSQL）：
CREATE OR REPLACE FUNCTION upsert_user(_id INT, _name TEXT, _email TEXT)
RETURNS VOID AS $$
BEGIN
INSERT INTO users (id, name, email, updated_at)
VALUES (_id, _name, _email, NOW())
ON CONFLICT (id) DO UPDATE
SET name = EXCLUDED.name,
email = EXCLUDED.email,
updated_at = NOW();
END;
$$ LANGUAGE plpgsql;
关键点：
-
ON CONFLICT (id)是固定写死的，哪怕你传入不同字段组合也不能改——冲突目标必须与索引定义完全一致 - 所有业务逻辑（如空值过滤、时间戳生成）都放在
VALUES或SET表达式里，不要试图在DO UPDATE外再加IF EXISTS查询 - 如果需要按不同唯一键做 Upsert（比如有时按
email，有时按id），得写多个函数，或用ON CONSTRAINT+ 显式约束名（更可控）
PostgreSQL v19 的 ON CONFLICT DO SELECT 能在存储过程中用吗？
可以，但必须搭配 RETURNING *，且返回结果要被函数捕获（比如用 RETURN QUERY 或临时表）。它不会自动“返回给调用方”，除非你显式处理。
典型误用：
- 写了个函数返回
SETOF users，但忘了在INSERT ... ON CONFLICT DO SELECT后加RETURNING *→ 实际什么也不返回 - 以为
DO SELECT会跳过插入直接查，其实它仍会尝试插入；只是冲突时返回已有行，而非抛错 - 在事务块里多次调用该函数，却没注意
RETURNING的结果集可能被上层客户端丢弃（尤其 JDBC/ODBC 驱动默认不读 multiple result sets）
最易被忽略的一点：v19 的 DO SELECT 仍是实验性增强，部分云厂商（如旧版 AnalyticDB for PostgreSQL）尚未同步支持，上线前务必验证内核版本和文档兼容性。
