Re: Can we remove support for standard_conforming_strings = off yet?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-31T17:04:41Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Force standard_conforming_strings to always be ON.
- 45762084545e 19 (unreleased) landed
-
Doc: remove obsolete, confused <note> about rowtype I/O syntax.
- d6542f8dfc6c 19 (unreleased) landed
Andrew Dunstan <andrew@dunslane.net> writes: > On 2025-12-30 Tu 5:50 PM, Tom Lane wrote: >> 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. > Have we ever promised that dumps made using pg_dump/pg_dumpall from > other than the target version work? We may not promise it, but I think we've always tried very hard to not break old pg_dump files, precisely because they might be the only available backup. > I don't see this as a big issue, unless I'm misunderstanding. Personally I would call it a deal-breaker if I thought it'd affect more than a very very tiny number of people. But the entire premise of this patch is that nobody is using standard_conforming_strings = off in production anymore. If that isn't true it's probably a mistake to go forward anyway. regards, tom lane