PostgreSQL 22001 string_data_right_truncation: value too long

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

   Identify the target column or type from the ErrorResponse fields

   No special tools

   Who:

   Your developer or DBA reviewing the failed SQL statement for 22001.

   How:

   Read the ErrorResponse fields M (Message), P (Position, measured in characters starting at 1), s (Schema name), t (Table name), c (Column name), and d (Data type name) after redacting personal data and credentials.

   Result that matters:

   The primary message (such as ERROR: value too long for type character varying(5)) and cursor position pinpoint the column or expression that rejected the string.

   If the message and position point to a specific table column in an INSERT or UPDATE, that confirms column assignment triggered 22001 rather than an internal server failure.

   If the error includes Internal position (p) and Where (W) stack lines, that indicates a PL/pgSQL variable or internal query inside a function exceeded its bounded character type.

   Evidence to keep:

   Save the redacted ErrorResponse fields C, M, P, s, t, c, d, and W with the failure timestamp.

   Evidence: PostgreSQL 18 Appendix A: Error Codes · PostgreSQL error and notice fields · PostgreSQL 18 character types

2. 2

   Check declared character_maximum_length in information_schema.columns

   Tools required

   Who:

   Your developer or database administrator with SELECT privilege on the target table.

   How:

   Run a read-only query on information_schema.columns for table_schema, table_name, column_name, data_type, character_maximum_length, character_octet_length, and domain_name.

   Result that matters:

   The view reports the declared character limit (character_maximum_length) alongside the underlying type and any domain wrapper.

   If character_maximum_length is smaller than the incoming string length in characters, that confirms the schema limit is tighter than the payload submitted by the client.

   If data_type is character with character_maximum_length equal to 1 because char was declared without a specifier, that points to an unintended single-character column definition.

   Evidence to keep:

   Record the query output showing column_name, data_type, character_maximum_length, and domain_name.

   Run only read-only SELECT queries against information_schema.columns; never alter production column types before rolling back any aborted transaction and checking downstream dependencies.

   Evidence: PostgreSQL 18 information_schema columns view · PostgreSQL 18 character types

3. 3

   Measure the rejected input with char_length and test with pg_input_error_info

   Tools required

   Who:

   Your application developer testing a redacted sample of the 22001 payload.

   How:

   Issue ROLLBACK first if your interactive session is inside a failed transaction block, then run SELECT char_length($1) and SELECT * FROM pg_input_error_info($1, 'varchar(5)') using your target type declaration.

   Result that matters:

   char_length counts characters (not bytes) and pg_input_error_info returns message and sql_error_code 22001 without aborting the session when soft error reporting applies.

   If char_length exceeds n and the trailing characters include non-spaces, that confirms why PostgreSQL raised 22001 instead of applying the SQL-standard trailing-space truncation exception.

   If char_length is within n for the table column, that rules out that column as the culprit and points to a narrower trigger variable or intermediate target in the same transaction.

   Evidence to keep:

   Keep the char_length integer reading and the row returned by pg_input_error_info.

   Do not test with unredacted customer secrets or passwords in shared logs, and never silently truncate identifiers or business keys to bypass 22001.

   Evidence: PostgreSQL ROLLBACK · PostgreSQL 18 system information functions · PostgreSQL 18 character types

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

In Appendix A Table A.1, the PostgreSQL server maps 22001 to string_data_right_truncation under Class 22 Data Exception. Section 8.3 states that character varying(n) and character(n) store strings up to n characters (not bytes) in length, and storing a longer string into a table column raises an error unless the excess characters are all spaces. By contrast, an explicit cast to character varying(n) or character(n) truncates an over-length value to n characters without raising an error. The 22001 code alone does not prove a database server fault or identify which column overflowed; read the error message and protocol fields to locate the target.

• Mediumsource verified

  Never cast primary keys, external identifiers, email addresses, or security tokens to varchar(n) just to silence SQLSTATE 22001: Section 8.3 states that an explicit cast truncates over-length strings to n characters without raising an error, which can corrupt records or merge distinct identities.

  Evidence: PostgreSQL 18 Appendix A: Error Codes · PostgreSQL 18 character types

• Lowsource verified

  Do not attempt to disable constraints, triggers, or durability settings to force an oversized string write, and always issue ROLLBACK to clear an aborted transaction block before running follow-up commands; redact personal data and connection strings before sharing error logs.

  Evidence: PostgreSQL error and notice fields · PostgreSQL ROLLBACK

1. 1

   PostgreSQL 18 Appendix A: Error Codes

   PostgreSQL Global Development Group · 2026 · official_doc

2. 2

   PostgreSQL error and notice fields

   PostgreSQL Global Development Group · 2026 · official_doc