The B cluster’s first historical artifact. backslash_quote controls whether \' is accepted as a way of representing a single quote inside a SQL string literal. It exists because of a 2006 SQL injection vulnerability involving multibyte character encodings, and almost twenty years on it is still in the GUC list because removing it would break some application somewhere. PostgreSQL is conservative about these things.

The original problem

The SQL standard represents an embedded quote by doubling it: 'it''s a quote'. PostgreSQL has historically also accepted backslash escaping in non-standard string literals: 'it\'s a quote' (in legacy non-standard-conforming mode) or E'it\'s a quote' (in standard mode, with the explicit E prefix). The backslash form predates the SQL standard and was widespread in real applications.

In 2006, the Japanese developer community demonstrated an SQL injection technique against PHP applications using Shift-JIS encoding. The mechanic: some multibyte client encodings (SJIS, BIG5, GBK, GB18030, UHC) contain characters whose trailing byte is 0x5C — numerically identical to ASCII backslash. If client-side escaping code is encoding-naive and treats every 0x5C byte as a backslash to be doubled, an attacker can craft a multibyte character such that the encoding-naive escaper doubles the 0x5C inside the multibyte sequence, producing what the server sees as a legitimately-terminated escape followed by attacker-controlled SQL.

The server-side mitigation that emerged was backslash_quote.

What the parameter does

Three values:

  • on — accept \' always. This is the old, insecure-by-default-in-some-encodings behavior. Provided for backward compatibility with applications that need it.
  • off — reject \' always. Forces application code to use the standard '' form. Most strict.
  • safe_encoding — accept \' only when the client encoding cannot produce the multibyte/0x5C confusion. UTF-8 is safe. SJIS, BIG5, GBK, GB18030, UHC are not.

safe_encoding is the default, and has been since the 2006 patch landed. Context is user, so per-session override is possible.

A demonstration of off rejecting a backslash-escaped quote:

1SET backslash_quote TO off;


2SELECT E'hello \'world\'!';


3-- ERROR: unsafe use of \' in a string literal


4-- HINT: Use '' to write quotes in strings.

Why this is mostly irrelevant in 2026

Three reasons:

  1. standard_conforming_strings = on has been the default since PostgreSQL 9.1 (2011). In a standard-conforming literal, \ is just a literal backslash, so \' doesn’t escape anything — the apostrophe terminates the string. backslash_quote only governs behavior inside E'...' strings and the deprecated non-standard mode.
  2. Parameterized queries make the entire question moot. If your client code uses $1, $2, $3 placeholders and passes values out-of-line, no escaping happens, no quote injection is possible, and the parameter is irrelevant. Every modern client library does this. If yours doesn’t, that is a bigger problem than this GUC.
  3. UTF-8 is universal. Nobody is running a new application on SJIS in 2026.

When to change it

  • backslash_quote = off is reasonable as a belt-and-suspenders setting for paranoid environments. It forces application code to use the standard form, which is good hygiene regardless of the security argument. Cost: any application that still emits E'foo\'bar' will break.
  • backslash_quote = on has essentially no legitimate use. If you have an application that needs it, your application is the problem.

Recommendation: Leave at safe_encoding. The default has been correct since 2006, your client is almost certainly using parameterized queries, your encoding is almost certainly UTF-8, and the entire threat model the parameter addresses is two decades and several layers of mitigation removed from your actual production system. The parameter exists for the same reason array_nulls exists: nobody wants to break the one application that depends on it.