PostgreSQL warns with SQLSTATE 22P06 when a backslash escape is used in a standard-conforming single-quoted string.
PostgreSQL Error 22P06 – nonstandard_use_of_escape_character – appears when a backslash is found in a regular single-quoted string while standard_conforming_strings is on. Prefix the literal with E, use dollar quoting, or pass the value as a bind parameter to remove the warning.
PostgreSQL Error 22P06
PostgreSQL assigns SQLSTATE 22P06 when it detects a backslash escape sequence in a standard_conforming_strings environment. The server regards the backslash as a nonstandard escape character and emits the notice nonstandard_use_of_escape_character. Execution continues, but PostgreSQL highlights that the string may not behave as ANSI SQL expects.
Many teams ignore the message until queries silently mishandle paths or JSON fragments.
Treating the notice as an error in CI or production prevents risky data manipulation and keeps code portable across databases.
The notice appears whenever a backslash is found inside a single-quoted literal without the legacy E'' escape string syntax and while standard_conforming_strings is on.
PostgreSQL thinks you intended an escape such as \n or \t, yet ANSI SQL treats the backslash as ordinary text.
It also surfaces when client libraries or ORMs double-escape backslashes, creating SQL like 'C:\\temp'. Even when the value is correct, PostgreSQL flags the syntax because it deviates from the SQL standard.
Replace the string with an ANSI-compliant form. Prefix the literal with E so PostgreSQL knows to interpret backslashes: E'C:\\temp'.
You can also switch to dollar quoting or pass the value as a bind parameter.
Galaxy’s SQL editor highlights unsafe backslashes and can auto-rewrite literals into E-strings or parameter placeholders, eliminating the warning before code reaches production.
Windows file paths often trigger the warning. Convert INSERT statements such as 'C:\\Program Files\\app' into E'C:\\Program Files\\app' or store the path with forward slashes.
JSON bodies assembled in application code may include "\\n".
Pass the string as a parameter or wrap it in dollar quoting: $${"line":"first\nsecond"}$$ to keep the literal untouched.
Enable standard_conforming_strings and force escape string syntax in development. Treat any 22P06 notice as an error during automated testing to surface problems early.
Prefer parameterized queries in application code.
When crafting ad-hoc SQL in Galaxy, use its E-string or dollar-quote snippets to insert backslashes safely.
SQLSTATE 42601 syntax error at or near "\\" is raised when the backslash breaks tokenization. Apply the same E'' or dollar quoting fixes.
SQLSTATE 22P02 invalid text representation can follow if an unintended escape changes the string. Sanitizing literals with E-strings or parameters prevents both 22P06 and 22P02.
.
No. PostgreSQL treats it as a WARNING. The statement runs, but you should still fix it for portability and safety.
Set standard_conforming_strings to off, but this is discouraged. Prefer E-strings, dollar quoting, or parameters.
Versions 9.1 and later raise the notice when standard_conforming_strings is on (default since 9.1).
Yes. Galaxy’s linter flags raw backslashes and offers one-click rewrites to E-strings or parameters, eliminating the warning before deployment.
.avif)
.avif){kind=logo}
