Skip to content

escape_string_warning

escape_string_warning — Warn about backslash escapes in ordinary string literals. Observed in PG9.0–18; its last measured boot default is on in PG18, with user context. It was removed in PG19 Beta 3.
Note

Fact — official short description: “Warn about backslash escapes in ordinary string literals.”

Identity

Type , Valuebool
Upstream pg_settings type
Context , Valueuser
Settable by an ordinary user
Unit , Value—
Raw unit
Range , Value—
Raw limits in the last observed version
Enum values , Value—
— for non-enum types
Category , ValueVersion and Platform Compatibility / Previous PostgreSQL Versions
Upstream classification
Latest boot value , Valueon
on

Lifecycle

Fact Value
First observed PG9.0 (research boundary)
Present in PG9.0–18
Removed in PG19 Beta 3
Introduction commit Not asserted: predates the PG9.0 research boundary
Commit date —
Discussion —

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG9.0–18 on — on

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload Guidance
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.
OLAP Regression-test ETL, generated SQL, and old drivers, where parsing/quoting assumptions hide. Performance is rarely a reason to change this switch.
Small nodes Keep the default without a legacy requirement. If temporarily enabled, record owner, affected connections, and a removal date.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG18; this does not assert current Pigsty support for that historical or beta release.

Template Effective value Versus upstream boot Source expression
OLTP Unmodified — —
OLAP Unmodified — —
CRIT Unmodified — —
TINY Unmodified — —
Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–18 unmodified; OLAP: PG9.0–18 unmodified; CRIT: PG9.0–18 unmodified; TINY: PG9.0–18 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

  • 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.

array_nulls · backslash_quote · standard_conforming_strings · transform_null_equals · quote_all_identifiers · default_with_oids

References