From: Tom Lane <tgl@sss.pgh.pa.us>
To: Baji Shaik <baji.pgdev@gmail.com>
cc: pgsql-hackers@lists.postgresql.org, Bruce Momjian <bruce@momjian.us>
Subject: Re: [PATCH] Doc: document standard_conforming_strings dump/restore
 incompatibility
In-reply-to: 
 <CA+fm-RM8bG0G6SJDaMgWkKmtyf4QG=V5We1ViAG0tZ5PU67rLQ@mail.gmail.com>
References: 
 <CA+fm-RM8bG0G6SJDaMgWkKmtyf4QG=V5We1ViAG0tZ5PU67rLQ@mail.gmail.com>
Comments: In-reply-to Baji Shaik <baji.pgdev@gmail.com>
	message dated "Mon, 11 May 2026 17:21:57 -0500"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1131479.1781717330.0@sss.pgh.pa.us>
Date: Wed, 17 Jun 2026 13:29:09 -0400
Message-ID: <1131492.1781717349@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1131492.1781717349%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1131479.1781717330.1@sss.pgh.pa.us>

Baji Shaik <baji.pgdev@gmail.com> writes:
> Commit 45762084 [1] forced standard_conforming_strings to always be ON in
> PostgreSQL 19. The release notes mention this change, but neither the
> pg_dump/pg_restore reference pages nor the migration section note the
> implications for restoring older dump files.

Okay, that's an oversight in the release notes for sure.  I'm more
skeptical about putting such information into the application
reference pages though.  It seems of only transient interest, but
any text we put there is likely to survive for many years.

Independently of that...

> The attached patch adds notes to:
> - pg_dump reference page (Notes section)
> - pg_restore reference page (Notes section)
> - release-19 migration section

I don't like this patch, because it presents much too rosy a view of
whether you can get away with not re-taking the dump.  It's unsafe
even with COPY-format data, because string literals in views, table
default expressions and constraints, function definitions, etc are all
at hazard of being misinterpreted.  I think we should just say it
won't work correctly, full stop.

I'm inclined to do more or less the attached, which also fixes what
seems a thinko in the existing text: we should say that clients still
support standard_conforming_strings = off, not
escape_string_warning = off.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="v2-document-dump-restore-hazard.patch";
	charset="us-ascii"
Content-ID: <1131479.1781717330.2@sss.pgh.pa.us>
Content-Description: v2-document-dump-restore-hazard.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 285bfa123f6..4943885cf01 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -109,7 +109,18 @@ Force <link linkend=3D"guc-standard-conforming-string=
s"><varname>standard_conformi
 </para>
 =

 <para>
-Server variable <varname>escape_string_warning</varname> has been removed=
 as unnecessary.  Client applications still support <literal>escape_string=
_warning =3D off</literal> for compatibility with old servers.
+This carries some risk for upgrades: a dump file produced by
+pre-v19 <application>pg_dump</application> from a server that
+had <literal>standard_conforming_strings =3D off</literal>
+will not restore correctly into v19 or later.  Use
+v19 <application>pg_dump</application> to take the dump, or
+set <literal>standard_conforming_strings =3D on</literal>
+in the old server before dumping.
+Client applications still support operations with servers
+having <literal>standard_conforming_strings =3D off</literal>, for
+compatibility with old servers.
+Server variable <varname>escape_string_warning</varname> has been removed
+as unnecessary.
 </para>
 </listitem>
 =


------- =_aaaaaaaaaa0--