Date: Wed, 17 Jun 2026 19:34:41 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Baji Shaik <baji.pgdev@gmail.com>, pgsql-hackers@lists.postgresql.org
Subject: Re: [PATCH] Doc: document standard_conforming_strings dump/restore
 incompatibility
Message-ID: <ajMvEd0zXBMN-Bri@momjian.us>
References: 
 <CA+fm-RM8bG0G6SJDaMgWkKmtyf4QG=V5We1ViAG0tZ5PU67rLQ@mail.gmail.com>
 <1131492.1781717349@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="06u5rFDaWFxiMbBd"
Content-Disposition: inline
In-Reply-To: <1131492.1781717349@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/ajMvEd0zXBMN-Bri%40momjian.us>
Precedence: bulk


--06u5rFDaWFxiMbBd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jun 17, 2026 at 01:29:09PM -0400, Tom Lane wrote:
> 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.

I have applied a slightly modified version to master, attached.  The git
commit suggested this problem, but I didn't understand the impact at the
time I read it.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.

--06u5rFDaWFxiMbBd
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="master.diff"

diff --git a/doc/src/sgml/release-19.sgml b/doc/src/sgml/release-19.sgml
index 285bfa123f6..911a198e676 100644
--- a/doc/src/sgml/release-19.sgml
+++ b/doc/src/sgml/release-19.sgml
@@ -109,7 +109,14 @@ Force <link linkend="guc-standard-conforming-strings"><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 = off</literal> for compatibility with old servers.
+Dumps created using pre-<productname>PostgreSQL</productname> 19 versions of <link linkend="app-pgdump"><application>pg_dump</application></link>
+or <link linkend="app-pg-dumpall"><application>pg_dumpall</application></link>, and using <literal>standard_conforming_strings = off</literal>,
+will not properly load into <productname>PostgreSQL</productname> 19 and later servers.  Users should create dumps using <productname>PostgreSQL</productname> 19
+or later versions of these applications, or use <literal>standard_conforming_strings = on</literal>.
+</para>
+
+<para>
+Client applications still support <literal>escape_string_warning = off</literal> for compatibility with old servers.  The server variable <varname>escape_string_warning</varname> has been removed as unnecessary.
 </para>
 </listitem>
 

--06u5rFDaWFxiMbBd--