On Tue, 2025-10-14 at 12:14 +0000, PG Doc comments form wrote:
> The description of BPCHAR in section 8.3. Character Types is
> misleading and
> incomplete.
Hi,
There was a previous discussion here:
https://www.postgresql.org/message-id/E1odZyZ-0000g2-AE%40gemulon.postgresql.org
> The first problem is that, contrary to table 8.4, BPCHAR is not
> actually
> blank-trimmed. The wording "as-if-blank-trimmed" or "blank-ignoring"
> may be
> better suited here. The following query explains the problem:
Correct, it does not actually trim the blanks before storing. The
paragraph below the table clarifies: "If bpchar lacks a length
specifier, it also accepts strings of any length, but trailing spaces
are semantically insignificant."
I think "blank-insignificant" is slightly better than "blank-ignoring".
> The second problem is that 'Tip' before the example 8.1 mentions only
> three
> types, also in a misleading way: 'There is no performance difference
> among
> these three types' - as if there were only 3, not 4 distinct types.
Thank you.
Please take a look at the attached patch. If you'd like your name
included in the commit, please send it as you'd like it to appear.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index b81d89e2608..ed9c1cba211 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -1178,7 +1178,7 @@ SELECT '52093.89'::money::numeric::float8;
</row>
<row>
<entry><type>bpchar</type></entry>
- <entry>variable unlimited length, blank-trimmed</entry>
+ <entry>variable unlimited length, blank-insignificant</entry>
</row>
<row>
<entry><type>text</type></entry>
@@ -1298,7 +1298,7 @@ SELECT '52093.89'::money::numeric::float8;
<tip>
<para>
- There is no performance difference among these three types,
+ There is no performance difference among these four types,
apart from increased storage space when using the blank-padded
type, and a few extra CPU cycles to check the length when storing into
a length-constrained column. While
