From 0ad1a816320a2b539a51628e2a0b1e83ff096b1d Mon Sep 17 00:00:00 2001
From: Andrew Dunstan <andrew@dunslane.net>
Date: Tue, 3 Jun 2014 16:11:31 -0400
Subject: Do not escape a unicode sequence when escaping JSON text.

Previously, any backslash in text being escaped for JSON was doubled so
that the result was still valid JSON. However, this led to some perverse
results in the case of Unicode sequences, These are now detected and the
initial backslash is no longer escaped. All other backslashes are
still escaped. No validity check is performed, all that is looked for is
\uXXXX where X is a hexidecimal digit.

This is a change from the 9.2 and 9.3 behaviour as noted in the Release
notes.

Per complaint from Teodor Sigaev.
---
 doc/src/sgml/release-9.4.sgml | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

(limited to 'doc/src')

diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index 08307c8f667..3f30c636ba2 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -180,6 +180,21 @@
      </para>
     </listitem>
 
+    <listitem>
+     <para>
+      Unicode escapes in <link linkend="datatype-json"><type>JSON</type></link>
+      text values are no longer rendered with the backslash escaped.
+      (Andrew Dunstan)
+     </para>
+
+     <para>
+      Previously all backslashes in text values being formed into JSON were
+      escaped. Now a backslash followed by "u" and four hexadecimal digits is
+      not escaped, as this is a legal sequence in a JSON string value, and
+      escaping the backslash led to some perverse results.
+     </para>
+    </listitem>
+
     <listitem>
      <para>
       Rename <link linkend="SQL-EXPLAIN"><command>EXPLAIN
-- 
cgit v1.2.3