escape_string_warning

Definition PG 18 manual

When on, a warning is issued if a backslash (\) appears in an ordinary string literal ('...' syntax) and standard_conforming_strings is off. The default is on.

Applications that wish to use backslash as escape should be modified to use escape string syntax (E'...'), because the default behavior of ordinary strings is now to treat backslash as an ordinary character, per SQL standard. This variable can be enabled to help locate code that needs to be changed.

How it works

Warn about backslash escapes in ordinary string literals. It can be changed at session scope, so different sessions may observe different behavior.

When standard_conforming_strings is off, this warns about backslashes in ordinary strings so applications can migrate to standard literals or explicit E'...' strings. It diagnoses legacy SQL; it does not change parsing by itself.

Monitor and change escape_string_warning together with array_nulls, backslash_quote, standard_conforming_strings. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Keeping a compatibility switch permanently instead of fixing the client.

Testing in one session and deploying globally to unrelated applications.

Confusing parsing compatibility with data or security compatibility.

Forgetting to remove an override after the upgrade migration is complete.

Workload guidance

OLAP: Regression-test ETL, generated SQL, and old drivers, where parsing/quoting assumptions hide. Performance is rarely a reason to change this switch.

OLTP: Keep the modern default and repair legacy clients/SQL that depend on escape_string_warning. Test migration at session scope first; do not make a compatibility switch permanent cluster policy.

SMALL: Keep the default without a legacy requirement. If temporarily enabled, record owner, affected connections, and a removal date.