public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: Tom Lane <[email protected]>
Cc: Baji Shaik <[email protected]>
Cc: [email protected]
Subject: Re: [PATCH] Doc: document standard_conforming_strings dump/restore incompatibility
Date: Wed, 17 Jun 2026 19:34:41 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+fm-RM8bG0G6SJDaMgWkKmtyf4QG=V5We1ViAG0tZ5PU67rLQ@mail.gmail.com>
<[email protected]>
On Wed, Jun 17, 2026 at 01:29:09PM -0400, Tom Lane wrote:
> Baji Shaik <[email protected]> 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 <[email protected]> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
Attachments:
[text/x-diff] master.diff (1.3K, ../[email protected]/2-master.diff)
download | inline 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>
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Doc: document standard_conforming_strings dump/restore incompatibility
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox