# 23000 — 完整性约束冲突（integrity_constraint_violation）

> PostgreSQL SQLSTATE 23000：完整性约束冲突的来源与诊断参考。
---

# 23000 — 完整性约束冲突

## 速览 {#at-a-glance}

`23000` 是 Class 23 完整性约束冲突的总类名，不是可以替代具体错误码的自然触发码。客户端应使用服务器返回的完整五字符 SQLSTATE。

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| 字段 | 值 |
| --- | --- |
| SQLSTATE | `23000` |
| 条件名 | `integrity_constraint_violation` |
| 状态 | `有效` |
| 已知存在于 | `7.4` |
| 锁定快照 | `9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` |
| 宏 | `ERRCODE_INTEGRITY_CONSTRAINT_VIOLATION` |
| 别名 | `—` |

<!-- source facts: data/errcodes/23000.json -->
<!-- END SQLSTATE FACTS -->

## 含义 {#meaning}

该类包含违反声明完整性规则的行和模式操作。锁定的 `errcodes.txt` 将具体机制分到 `23001`、`23502`、`23503`、`23505`、`23514`、`23P01` 等子码；18.6 核心调用扫描没有解析出的 `23000` 报文路径，因此本文不伪造运行复现。

## 诊断 {#diagnosis}

先读取精确 SQLSTATE，再查看 `constraint_name`、`table_name`、`column_name`、`schema_name` 以及主报文/DETAIL。把所有 Class 23 错误压成 `23000` 会丢失修复所需的对象和机制。

## 处理 {#response}

保留原语句及事务边界，按具体子码修复数据或约束；显式事务报错后先回滚。不要用 `RAISE ... ERRCODE 23000` 冒充自然服务器机制。

## 源码报文模板 {#messages}


## 适用边界 {#case}

本批没有为 `23000` 构造自然 SQL 触发器；请把它视为源码/协议边界，而不是可直接复制的复现脚本。[结构化证据](../../data/evidence/23000.json) · [案例导出](../../data/cases/23000.json)。

作者证据 ID：`identity`, `specific-codes`, `handling`。选定运行记录：—。

## 版本与边界 {#versions}

锁定目录在 `7.4` 已观察到该总类，并在列出的 9.0–18.6 正式快照中均存在。18.6 调用扫描确认了有界源码观察；本文不把它解释为扩展或未来版本都不可能发出该码。

## 相关 {#related}

参见 [23001 RESTRICT 冲突](../23001/)、[23502 非空约束冲突](../23502/)、[23514 CHECK 冲突](../23514/)、[23P01 排除约束冲突](../23p01/) 和 [23505 唯一约束冲突](../23505/)。

## 来源 {#sources}

- [`src.errcodes.18.6`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/errcodes.txt) (SHA-256 `6e8de346643ba84aa3c9c6a73360acfc7b2dfb89162c06c08ce9bf5bcd5bbcba`)
- `src.calls.REL_18_6` (SHA-256 `9ee8a0e81d8f0825c5c1ae45583439859a26e602bdd4ce2f2a62aa278867ccbf`)