diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2015-09-16 14:50:12 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2015-09-16 14:50:12 -0400 |
commit | d0f18cde7e40f1f6412bb35e8645888cd620682f (patch) | |
tree | 6ee112f7f237783b359805a7f0573fa8be1e124f | |
parent | 4d0fc1d54b465d4a40b3cf89908438533680e7f3 (diff) | |
download | postgresql-d0f18cde7e40f1f6412bb35e8645888cd620682f.tar.gz postgresql-d0f18cde7e40f1f6412bb35e8645888cd620682f.zip |
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.
-rw-r--r-- | doc/src/sgml/func.sgml | 21 |
1 files changed, 17 insertions, 4 deletions
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 22d4f615259..91a9379ae77 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -4669,7 +4669,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> @@ -4695,15 +4695,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> @@ -4753,6 +4755,17 @@ SELECT foo FROM regexp_split_to_table('the quick brown fox', E'\\s*') AS foo; </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 <literal>\135</> does not terminate a bracket expression. |