MIME-Version: 1.0
References: <176044409338.770.16064383081308443747@wrigleys.postgresql.org>
 <e9ad2cb03195402a96e8cb9130470bfca3bf49c7.camel@j-davis.com>
 <1307875.1760556576@sss.pgh.pa.us>
In-Reply-To: <1307875.1760556576@sss.pgh.pa.us>
From: Sergei Katkovsky <skatkovsky@gmail.com>
Date: Thu, 16 Oct 2025 10:53:59 +0400
Message-ID: 
 <CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg@mail.gmail.com>
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and
 incomplete
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-docs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg%40mail.gmail.com>
Precedence: bulk

> I don't understand why any of these variants are better than the
> original wording "blank-padded".  That has the non-negligible
> advantage of corresponding to the type name, and furthermore
> appears in many other places in our docs and source code.

The wording for BPCHAR (not to be confused with BPCHAR(N) is already
"blank-trimming", not "blank-padded". And "blank-padded" is probably
the least correct wording variant for BPCHAR, because this type has
unlimited length and it's impossible to pad to the infinity.

The following example (slight modification of my original example, I
replaced varchar with bpchar(6)) can perhaps explain the difference.

SELECT  length(bpchar_val) as bplen, concat('[', bpchar_val, ']') as bpbrack
    , length(char6_val) as c6len, concat('[', char6_val, ']') as c6brack
FROM (VALUES
    ('abc   '::bpchar, 'abc   '::bpchar(6)),
    ('abc   '::bpchar, 'abc'::bpchar(6)),
    ('abc'::bpchar, 'abc   '::bpchar(6)),
    ('abc'::bpchar, 'abc'::bpchar(6)))
AS bpchar_test (bpchar_val, char6_val)
WHERE bpchar_val = char6_val;

There results are:
bplen  bpbrack   c6len  c6brack
3      [abc   ]  3      [abc   ]
3      [abc   ]  3      [abc   ]
3      [abc]     3      [abc   ]
3      [abc]     3      [abc   ]

As you can see, there are four rows, so, comparison ignores blanks,
length() also ignores blank, but the results of concatenation show
that while BPCHAR(6) was actually padded to 6 characters ('abc' became
'abc   '), BPCHARwas not. 'abc' remained 'abc'. Therefore, I don't
think it's a good idea to call BPCHAR "blank-padded".

With best regards,
Sergei Katkovskii