Incident brief
Invalid LIKE ESCAPE string
The ESCAPE clause of LIKE accepts an empty string or exactly one character; a multi-character escape string raises this data exception.
What lands in your log
ERROR: invalid escape string
In 10 seconds
- What triggers it
- Write a LIKE ... ESCAPE '<str>' where the escape string is longer than one character.
- Fix
- Use a single-character escape string, or an empty string to disable escaping.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 22025; the over-long escape string is rejected with a hint about the allowed length.
Fix
What to do right now
Application-level steps for this error.
- Use a single-character escape string, or an empty string to disable escaping.
- If the escape value is dynamic, validate its length before building the LIKE expression.
-- ESCAPE takes one character, or '' to disable escaping.
SELECT 'x' LIKE 'x' ESCAPE '';For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Invalid LIKE ESCAPE string (22025) is statement-local: PostgreSQL does not retain the rejected value after the statement ends. Capture the exact bound value and statement position in application/server logs, then run this targeted validation before retrying.
Validate LIKE escape length
Validate the specific value/shape that can raise this SQLSTATE.
SELECT escape_value, char_length(escape_value) AS characters,
char_length(escape_value) = 1 AS valid_like_escape
FROM (VALUES ('xx'::text)) v(escape_value);Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 18 Documentation, Appendix A. PostgreSQL Error Codes (Table A.1, Class 22, Data Exception)
22025 → invalid_escape_sequenceRead the full section on postgresql.org →
Passing a multi-character ESCAPE string
LIKE's escape string must be empty or a single character, so a longer string raises 'invalid escape string' with a hint to use one character.The session continues normally
The LIKE escape-string check failed outside a transaction block, so there's no ROLLBACK to perform before the next statement runs.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Write a LIKE ... ESCAPE '<str>' where the escape string is longer than one character.
- 2PostgreSQL validates the escape string before matching.
- 3Because it is neither empty nor a single character, the statement aborts with SQLSTATE 22025.
A search feature passed a user-supplied escape string straight into LIKE ... ESCAPE, and a multi-character value aborted the query.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT 'x' LIKE 'x' ESCAPE 'ab';SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: invalid escape string
HINT: Escape string must be empty or one character. session_after_error
---------------------
ok
(1 row)The same pattern matches once the escape string is empty or one character.
Without this
Before: a multi-character ESCAPE aborts
With this, tested
After: ESCAPE '' matches
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Related errors
Verification
- Last verified
- 2026-07-24 (isolated lab, PostgreSQL 18.4)
- Verification scope
- Verified against PostgreSQL 18.4 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.