Thread

Can we remove support for standard_conforming_strings = off yet?

Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-30T05:28:58Z

standard_conforming_strings has defaulted to ON since 2010 (see
0839f312e in the 9.1 release).  I propose that it's finally time to
force it on and get rid of code that supports the "off" setting.

Aside from pure code removal, there are nontrivial benefits that will
accrue:

* The setting has always been a bit of a security hazard, since
client code that escapes strings assuming one setting is at big
risk of SQL injection if the server is actually using the other.
We've disclaimed such issues as not-our-problem, but that doesn't
make them not a hazard.

* As discussed in the NOTES at the head of src/backend/parser/gram.y,
it's not okay for raw parsing to depend on changeable GUCs.  Sure,
gram.y doesn't use that setting; but scan.l does, so it's broken and
dangerous.  (See also the comment in scan.l above the declaration of
standard_conforming_strings.)

The code-removal aspect shouldn't be minimized either.  There's
a nontrivial portion of scan.l that isn't reachable unless
standard_conforming_strings is off, and reducing the size of the
lexer probably translates directly to performance benefits.

I would envision this working similarly to what we previously did with
default_with_oids: the GUC still exists so that applications can query
it, and we even allow you to explicitly set it to 'on'; only setting
it to 'off' will fail.

I haven't looked into subsidiary questions such as whether we can
similarly lobotomize escape_string_warning, or when it'd be okay to
remove the client-side support for non-standard-conforming strings
in the psql and ecpg lexers.  I'll push forward on those questions
if there's consensus that doing something about this is acceptable
in principle.

			regards, tom lane