Tom Lane wrote:
> hubert depesz lubaczewski <depesz@depesz.com> writes:
> > On Tue, May 10, 2011 at 06:20:23PM +0200, Martin Pitt wrote:
> >> Since HISTORY does not mention this, is that an explicit decision to
> >> finally deprecate the old \' syntax (which would be great, as it makes
> >> this thing a lot more robust and deterministic, but it might be worth
> >> mentioning it in HISTORY), or an unintended side effect?
>
> > release notes clearly mentions is:
> > http://developer.postgresql.org/pgdocs/postgres/release-9-1.html
> > - Change the default value of standard_conforming_strings to on (Robert Haas)
> > This removes a long-standing incompatibility with the SQL standard;
> > escape_string_warning has produced warnings about this usage for years. E''
> > strings are the proper way to embed escapes in strings and are unaffected by
> > this change.
>
> Hmm ... considering that's the first thing in the release notes, I'm
> surprised Martin missed it. Maybe he was looking for something
> mentioning backslashes ... should we add a bit that specifically says
> that backslashes are now no-ops by default?
I added the word "backslash" before escapes in the attached applied
patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
new file mode 100644
index d70c806..7737381
*** a/doc/src/sgml/release-9.1.sgml
--- b/doc/src/sgml/release-9.1.sgml
***************
*** 62,68 ****
standard; <link
linkend="guc-escape-string-warning"><varname>escape_string_warning</></link>
has produced warnings about this usage for years. <literal>E''</>
! strings are the proper way to embed escapes in strings and are
unaffected by this change.
</para>
</listitem>
--- 62,68 ----
standard; <link
linkend="guc-escape-string-warning"><varname>escape_string_warning</></link>
has produced warnings about this usage for years. <literal>E''</>
! strings are the proper way to embed backslash escapes in strings and are
unaffected by this change.
</para>
</listitem>
