22P06WARNINGTier 3 — Handle with care✅ HIGH confidencenonstandard use of escape character
What this means
SQLSTATE 22P06 is a Postgres-specific warning raised when a string literal uses a backslash escape (e.g., \n, \t) in a context where standard_conforming_strings is ON, making the backslash a literal character rather than an escape. This indicates portability risk.
Why it happens
- 1Using escape sequences like \n or \t in a regular string literal when standard_conforming_strings = on
- 2Code written for old Postgres versions (before 9.1) that used backslash escapes in ordinary string literals
How to reproduce
Using \n in a plain string literal with standard_conforming_strings = on.
SELECT 'Hello\nWorld'; -- \n is literal backslash+n, not newlineFix 1: Use escape string syntax (E prefix) when you need escape sequences
When the string genuinely requires escape sequences like \n or \t.
SELECT E'Hello\nWorld'; -- E prefix enables escape processingWhy this works
The E prefix explicitly enables escape processing regardless of standard_conforming_strings, making the intent clear and portable.
Fix 2: Use dollar-quoting for strings with backslashes
When the backslash is intended as a literal character.
SELECT $Hello\World$;Why this works
Dollar-quoted strings treat backslashes literally and suppress this warning.
What not to do
Set standard_conforming_strings = off to suppress the warning
Why it's wrong: This is a deprecated mode and will be removed. Fix the string literals instead.
Version notes
Postgres 9.1+standard_conforming_strings defaults to ON. Escape sequences in plain strings are deprecated.Sources
📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html
🔧 Source ref: Class 22 — Data Exception (Postgres-specific)
Confidence assessment
✅ HIGH confidence
Postgres-specific warning. Behaviour documented and stable since 9.1.
See also
🔗 Related errors
📄 Reference pages