Thread

Re: Can we remove support for standard_conforming_strings = off yet?

Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-30T22:50:10Z

I wrote:
> 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.

Here's a draft patch series for that.

As I was working through it, I realized that there's one
potentially-nasty point that might cause upgrading problems.
To wit, pg_dump and pg_dumpall have historically replicated the
source server's standard_conforming_strings setting into their
output: they emit a SET command for that, and any string literals
appearing in views or the like will be escaped accordingly.
So if your old installation had standard_conforming_strings = off,
and all you have from it is existing pg_dump output (either text
or archive format), you are in a sticky situation because that
dump will not restore cleanly.  This isn't impossible to get
out of, but you'd probably have to stand up a pre-v19 server,
restore the dump into that, and take a fresh dump made with
standard_conforming_strings = on.  The alternative would be
manual correction of literals in the dump script, which seems
far too error-prone to be recommendable.

This isn't a problem if you can make the dump with v19 pg_dump
(and therefore it's not an issue for pg_upgrade cases).  The attached
patch series tweaks pg_dump to force standard_conforming_strings = on
while dumping, so that it will produce a usable dump even if the
source server had the wrong default.

Nonetheless, if I thought there were more than epsilon existing
installations still running standard_conforming_strings = off
as a global setting, I'd worry that we still can't get away with
making this change.  But if I believed that, I wouldn't be
proposing it.  This observation does raise the stakes a bit though.

Another comment worth making is that I oversold the code-savings
benefit:

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

When I wrote that I was thinking we could get rid of the flex rules
for the <xe> exclusive state, but of course we cannot: those rules
are shared with the escape-string syntax E'...'.  In the attached,
the rules flex sees don't change at all.  We can get rid of the
code supporting escape_string_warning, because those warnings are
unreachable unless standard_conforming_strings = off.  But that's
no large amount of code.

I still think this is worth doing on the grounds of closing
edge-case security holes.  But perhaps it's not quite as
attractive as I thought yesterday.  A compromise position
could be to apply only 0003 attached to change pg_dump[all]'s
behavior, then wait a few more years so that the dump/reload
hazard is minimized before we reconsider the main patch.

Anyway, patches attached.

			regards, tom lane