PostgreSQL 23514 check_violation: row fails CHECK expression

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

1. 1

   Read the Constraint, Schema, Table, and Data type fields from ErrorResponse

   No special tools

   Who:

   You or your developer inspect the structured ErrorResponse fields returned for SQLSTATE 23514.

   How:

   Record protocol fields `n` (Constraint name), `s` (Schema name), `t` (Table name), `d` (Data type name, when a domain constraint failed), and `D` (Detail) using `\set VERBOSITY verbose` in `psql` or your driver's error properties.

   Result that matters:

   PostgreSQL supplies the exact constraint name in field `n` and either the table in `t` or the domain in `d`.

   If `n` and `t` are populated, that confirms a table or column `CHECK` constraint on table `t` evaluated to `FALSE` for the proposed row.

   If `d` is populated alongside `n`, that confirms a domain `CHECK` constraint rejected a value cast or assigned to that domain type.

   Evidence to keep:

   Save the exact `n`, `s`, `t`, `d`, and redacted `D` values from the error report.

   Evidence: PostgreSQL 18 Appendix A: Error Codes · PostgreSQL error and notice fields · PostgreSQL pg_constraint catalog

2. 2

   Extract the exact boolean expression with pg_get_constraintdef on pg_constraint

   Tools required

   Who:

   Your developer or DBA queries `pg_constraint` in a read-only session.

   How:

   Run `SELECT conname, conrelid::regclass AS table_name, contypid::regtype AS domain_name, connoinherit, convalidated, pg_get_constraintdef(oid, true) AS definition FROM pg_constraint WHERE conname = '<constraint_name>' AND contype = 'c';`.

   Result that matters:

   Table 52.13 recommends using `pg_get_constraintdef()` to extract the definition of a check constraint (`contype = 'c'`).

   If the decompiled `CHECK (...)` expression compares multiple columns (such as `CHECK (price > discounted_price)`), that confirms you must inspect the relationship between all referenced columns in the row, not a single field in isolation.

   If the expression calls a user-defined function, that points to testing that function's output on the rejected row values to see whether its logic changed.

   Evidence to keep:

   Keep the full `pg_get_constraintdef` string and the `table_name` or `domain_name` from `pg_constraint`.

   Perform read-only `SELECT` queries only; issue `ROLLBACK;` first if your client session is still inside the aborted transaction.

   Evidence: PostgreSQL constraints · PostgreSQL pg_constraint catalog · PostgreSQL 18 system information functions

3. 3

   Test the bound row values against TRUE, FALSE, and NULL semantics of CHECK

   Tools required

   Who:

   Your developer evaluates the exact bound values from the failed `INSERT` or `UPDATE` against the decompiled expression in a read-only `SELECT`.

   How:

   Run `SELECT (<check_expression>) IS FALSE AS fails_check` using the proposed column values (and any omitted columns' `DEFAULT` values) as constants.

   Result that matters:

   A `CHECK` constraint is satisfied if its expression evaluates to `TRUE` or `NULL` (`UNKNOWN`), and fails only when the result is `FALSE`.

   If the test `SELECT` returns `true` for `IS FALSE`, that confirms which specific column values or default values violated the expression.

   If the values you thought the app sent do not make the expression `FALSE`, that points to a `BEFORE` trigger or default expression modifying the row before constraint evaluation.

   Evidence to keep:

   Record the read-only test `SELECT` expression and the sanitized input values that produced `FALSE`.

   Do not test with live `INSERT` or `UPDATE` statements on production tables; evaluate the boolean expression in a read-only `SELECT`.

   Evidence: PostgreSQL constraints · PostgreSQL 18 CREATE TABLE

A code is meaningful only inside the right product and version context.

Appendix A of the PostgreSQL documentation assigns SQLSTATE 23514 to `check_violation` in Class 23 (Integrity Constraint Violation). A `CHECK` constraint requires column values in a new or updated table row (or domain value) to satisfy a boolean expression. In PostgreSQL, a `CHECK` expression succeeds when it evaluates to `TRUE` or `UNKNOWN` (null); an error is raised only when it evaluates to `FALSE`, leaving the table unchanged. `CHECK` constraints are checked immediately on row write in alphabetical order after `NOT NULL` checks and are never deferrable. The code alone does not prove whether a single column, a multi-column check, a default or a modified function caused the `FALSE` result.

• Mediumsource verified

  Never write `CHECK` constraints that reference other table rows or mutable functions, and never mark a constraint `NOT ENFORCED` just to bypass 23514; cross-row or mutable `CHECK` rules can cause a later database dump and restore to fail.

  Evidence: PostgreSQL constraints · PostgreSQL 18 CREATE TABLE

• Lowsource verified

  Do not attempt to include unredacted row payloads from `Detail` messages in bug reports or support tickets when those columns contain personal or financial data.

  Evidence: PostgreSQL error and notice fields · PostgreSQL bug reporting guidelines

1. 1

   PostgreSQL 18 Appendix A: Error Codes

   PostgreSQL Global Development Group · 2026 · official_doc

2. 2

   PostgreSQL constraints

   PostgreSQL Global Development Group · 2026 · official_doc