Beginning in PostgreSQL 19, this parameter is always on.
At a glance
| Property | Value |
|---|---|
| Parameter | standard_conforming_strings |
| Category | Version and Platform Compatibility |
| Default | (see documentation) |
| Value type | boolean (on/off) |
| Change scope | Per-session (SET) |
| Available in | PostgreSQL 12, 13, 14, 15, 16, 17, 18, 19 (added in 12) |
What it does
Beginning in PostgreSQL 19, this parameter is always on. String literals are always parsed as specified in the SQL standard (that is, backslashes are ordinary characters within a string literal). This parameter continues to exist because applications may consult it; but it cannot be set to off. Escape string syntax (syntax_strings_escape) should be used if an application desires backslashes to be treated as escape characters.
(Description quoted from the official PostgreSQL documentation.)
How to apply a change
Can be set per session with SET, per role/database with ALTER ROLE/DATABASE ... SET, or globally in postgresql.conf.
Inspect the current value and source with SHOW standard_conforming_strings; or SELECT name, setting, unit, context, source FROM pg_settings WHERE name = 'standard_conforming_strings';.
Tuning guidance
This controls backward-compatibility behaviour, not performance. Keep it at the modern default unless a specific legacy application depends on the older behaviour; turning compatibility flags on to paper over application bugs stores up problems for a future upgrade. Treat any non-default value as technical debt to remove.