PSQL或MyBatis触发重复行唯一约束冲突时，能否获取对应记录的siebel_id？

该需求完全可以落地，分别可以从PostgreSQL数据库层、MyBatis持久层两个方向实现，无需调整核心业务的原有流程

一、PostgreSQL 数据库层实现 #

PostgreSQL 从9.5版本开始原生支持冲突分支处理语法，不需要额外在应用层做预查询，就能在触发唯一约束冲突时直接读取已有行的字段值：

• 基于ON CONFLICT语法的原子实现
  日常场景下大家容易把ON CONFLICT和“upsert更新逻辑”绑定，实际上可以借助冲突分支的返回值，在不真正修改原有业务数据的前提下，拿到冲突行的目标字段：

  INSERT INTO client (siebel_id, phone_number)
  VALUES ('本次待插入的siebel_id值', '+79991234567')
  ON CONFLICT (phone_number) DO UPDATE
  -- 以下赋值为占位逻辑，不会实际改动原有数据
  SET phone_number = client.phone_number
  RETURNING
    CASE
      WHEN xmax = 0 THEN '记录新增成功' -- xmax为PostgreSQL内部行版本标记，值为0代表是新插入的行
      ELSE '手机号重复：该号码已绑定siebel_id=' || client.siebel_id
    END AS prompt_info;
  

  这种实现的核心优势是完全在单条数据库语句内完成，不存在应用层“先查后插”的并发竞态问题，事务原子性有保障。
• 基于异常触发器的原生报错格式实现
  如果不想改变原有“触发唯一约束直接抛错”的逻辑，可以在数据库端创建异常捕获触发器，当检测到phone_number_unique约束的冲突时，自动查询对应手机号的siebel_id，把值追加到原有异常的Detail信息里，实现你预期的原生报错格式：

  ERROR: duplicate key value violates unique constraint "phone_number_unique"
  Detail: Key (phone_number)=(+79991234567) already exists on siebel_id=SIEBEL_XXXX

二、MyBatis 持久层实现 #

如果不想调整数据库端的原有逻辑，完全可以在持久层完成信息补全，不需要改动数据库的表结构、约束和触发器：

• 异常精准捕获：通过JDBC返回的SQLState码23505精准定位唯一约束冲突类异常，再结合异常携带的约束名匹配phone_number_unique，避免和其他表的唯一约束冲突混淆。
• 结构化提取冲突值：不要靠正则解析报错文本，直接从JDBC驱动返回的结构化异常对象中，提取冲突的phone_number值（也就是报错里的Key (phone_number)=(xxx)对应的内容）。不同PostgreSQL版本下的异常文本可能调整，结构化字段的稳定性远高于文本匹配。
• 补全信息返回：拿着提取到的手机号值，发起一次轻量单表查询获取对应的siebel_id，将值拼接到最终抛出的业务错误提示中即可。

注意：千万不要用“先查手机号是否存在、不存在再插入”的流程替代异常捕获，高并发场景下两个请求可能同时判断手机号不存在，最终还是会触发唯一约束冲突，异常捕获逻辑需要作为最终兜底保留。

内容的提问来源于stack exchange，提问作者Maksym Rybalkin