select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / VERSION AND PLATFORM COMPATIBILITY

standard_conforming_strings

Read PG 18 manual ↗

This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard.

Type
bool
Context
user
Measured default
on
Unit
Metadata snapshot
18

Definition PG 18 manual

This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard. Beginning in PostgreSQL 9.1, the default is on (prior releases defaulted to off). Applications can check this parameter to determine how string literals will be processed. The presence of this parameter can also be taken as an indication that the escape string syntax (E'...') is supported. Escape string syntax (Section 4.1.2.2) should be used if an application desires backslashes to be treated as escape characters.

Measured default history
Version intervalDefault
9.0 – 9.0off
9.1 – 19on
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

Causes '...' strings to treat backslashes literally. It can be changed at session scope, so different sessions may observe different behavior.

With on, backslashes in ordinary '...' strings are literal and escape processing requires E'...'. Turning it off restores legacy parsing, making client/server disagreement and unsafe SQL construction more likely.

Monitor and change standard_conforming_strings together with array_nulls, backslash_quote, escape_string_warning. 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 standard_conforming_strings. 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.

Version history 2
  1. PG 18 → 19changed
  2. PG 9.0 → 9.1changed

Related entries

Further reading

Definition snapshot: english-manuals:be95ffaac7a0ea7361e84e24c45… · English manual source