From 78ed8e03c67d7333708f5c1873ec1d239ae2d7e0 Mon Sep 17 00:00:00 2001 From: Andrew Dunstan Date: Wed, 12 Jun 2013 13:35:24 -0400 Subject: Fix unescaping of JSON Unicode escapes, especially for non-UTF8. Per discussion on -hackers. We treat Unicode escapes when unescaping them similarly to the way we treat them in PostgreSQL string literals. Escapes in the ASCII range are always accepted, no matter what the database encoding. Escapes for higher code points are only processed in UTF8 databases, and attempts to process them in other databases will result in an error. \u0000 is never unescaped, since it would result in an impermissible null byte. --- doc/src/sgml/func.sgml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'doc/src') diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 3adb36579ea..4c5af4b83c8 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -10159,6 +10159,17 @@ table2-mapping + + + Many of these functions and operators will convert Unicode escapes + in the JSON text to the appropriate UTF8 character when the database encoding is UTF8. In + other encodings the escape sequence must be for an ASCII character, and any other code point + in a Unicode escape sequence will result in an error. + In general, it is best to avoid mixing Unicode escapes in JSON with a non-UTF8 database + encoding, if possible. + + + The extension has a cast from hstore to -- cgit v1.2.3