docs: document behavior of CHAR() comparisons with chars < space

Space trimming rather than space-padding causes unusual behavior, which
might not be standards-compliant.

Also remove recently-added now-redundant C comment.

1 files changed, 7 insertions, 4 deletions

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 00ccbe1bb5f..ebcadf617aa 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1078,10 +1078,13 @@ SELECT '52093.89'::money::numeric::float8;
    <para>
     Values of type <type>character</type> are physically padded
     with spaces to the specified width <replaceable>n</>, and are
-    stored and displayed that way.  However, the padding spaces are
-    treated as semantically insignificant.  Trailing spaces are
-    disregarded when comparing two values of type <type>character</type>,
-    and they will be removed when converting a <type>character</type> value
+    stored and displayed that way.  However, trailing spaces are treated as
+    semantically insignificant and disregarded when comparing two values
+    of type <type>character</type>.  In collations where whitespace
+    is significant, this behavior can produce unexpected results,
+    e.g. <command>SELECT 'a '::CHAR(2) collate "C" < 'a\n'::CHAR(2)
+    returns true.
+    Trailing spaces are removed when converting a <type>character</type> value
     to one of the other string types.  Note that trailing spaces
     <emphasis>are</> semantically significant in
     <type>character varying</type> and <type>text</type> values, and