postgres.git / summary / log / commit / refs

commit    f7eeb324e7b9fa948dfd55b55e9b20fa919e7f79
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Wed Sep 16 18:50:12 2015 +0000
First released in: 9.6.0, 9.0.23, 9.1.19, 9.2.14, 9.3.10, 9.4.5, 9.5.0

    Fix documentation of regular expression character-entry escapes.
    
    The docs claimed that \uhhhh would be interpreted as a Unicode value
    regardless of the database encoding, but it's never been implemented
    that way: \uhhhh and \xhhhh actually mean exactly the same thing, namely
    the character that pg_mb2wchar translates to 0xhhhh.  Moreover we were
    falsely dismissive of the usefulness of Unicode code points above FFFF.
    Fix that.
    
    It's been like this for ages, so back-patch to all supported branches.


 doc/src/sgml/func.sgml | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 0d614024a78..2b8cb99bb97 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -4148,7 +4148,7 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
        <entry> <literal>\e</> </entry>
        <entry> the character whose collating-sequence name
        is <literal>ESC</>,
-       or failing that, the character with octal value 033 </entry>
+       or failing that, the character with octal value <literal>033</> </entry>
        </row>
 
        <row>
@@ -4174,15 +4174,17 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
        <row>
        <entry> <literal>\u</><replaceable>wxyz</> </entry>
        <entry> (where <replaceable>wxyz</> is exactly four hexadecimal digits)
-       the UTF16 (Unicode, 16-bit) character <literal>U+</><replaceable>wxyz</>
-       in the local byte ordering </entry>
+       the character whose hexadecimal value is
+       <literal>0x</><replaceable>wxyz</>
+       </entry>
        </row>
 
        <row>
        <entry> <literal>\U</><replaceable>stuvwxyz</> </entry>
        <entry> (where <replaceable>stuvwxyz</> is exactly eight hexadecimal
        digits)
-       reserved for a hypothetical Unicode extension to 32 bits
+       the character whose hexadecimal value is
+       <literal>0x</><replaceable>stuvwxyz</>
        </entry>
        </row>
 
@@ -4231,6 +4233,17 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo;
     Octal digits are <literal>0</>-<literal>7</>.
    </para>
 
+   <para>
+    Numeric character-entry escapes specifying values outside the ASCII range
+    (0-127) have meanings dependent on the database encoding.  When the
+    encoding is UTF-8, escape values are equivalent to Unicode code points,
+    for example <literal>\u1234</> means the character <literal>U+1234</>.
+    For other multibyte encodings, character-entry escapes usually just
+    specify the concatenation of the byte values for the character.  If the
+    escape value does not correspond to any legal character in the database
+    encoding, no error will be raised, but it will never match any data.
+   </para>
+
    <para>
     The character-entry escapes are always taken as ordinary characters.
     For example, <literal>\135</> is <literal>]</> in ASCII, but


[parent: 698c7a3bc0d8]