22P05ERRORTier 2 — Caution✅ HIGH confidenceuntranslatable character
What this means
SQLSTATE 22P05 is a Postgres-specific error raised when a character in the input cannot be translated from the client encoding to the server (database) encoding. This is more specific than 22021 — it applies when the character exists in the source encoding but has no equivalent in the target encoding.
Why it happens
- 1A Unicode character exists in the client data but has no equivalent codepoint in the server encoding (e.g., a Unicode emoji in a LATIN-1 database)
- 2Encoding conversion table does not include the specific character
How to reproduce
Inserting emoji into a LATIN-1 database from a UTF-8 client.
-- client_encoding = UTF8, database encoding = LATIN1
INSERT INTO messages (body) VALUES ('Hello 🌍');Fix 1: Use a Unicode-capable database encoding (UTF-8)
When designing a new database that will handle multilingual or emoji content.
CREATE DATABASE mydb ENCODING 'UTF8' LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';Why this works
UTF-8 can represent all Unicode codepoints, eliminating untranslatable character errors.
Fix 2: Strip or replace untranslatable characters before inserting
When the database encoding cannot be changed.
-- Remove characters outside LATIN-1 range in the application layer before sending to PostgresWhy this works
Pre-process the string in the application to remove or replace characters not representable in the target encoding.
What not to do
Set client_encoding to LATIN-1 to hide UTF-8 characters
Why it's wrong: This causes Postgres to misinterpret the bytes rather than converting them, leading to silent data corruption.
Sources
📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html
📚 Feature docs: https://www.postgresql.org/docs/current/multibyte.html
🔧 Source ref: Class 22 — Data Exception (Postgres-specific)
Confidence assessment
✅ HIGH confidence
Postgres-specific error for encoding translation failures. Stable across versions.
See also
🔗 Related errors
📄 Reference pages