Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

On Thu, Oct 16, 2025 at 4:36 PM David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> A given value has a finite length and there is just no restriction on what that length is. All trailing spaces in the input are considered padding for purposes of comparison i.e., manually padding is added by the user as opposed to the system.

A given value of BPCHAR is stored as is, without padding or trimming
(contrary to the current wording in Table 8.4 about black-trimming).
But what is the point of saying that it is manually padded, if the
user is free to store it without any padding? And, although
technically you can say that BPCHAR is blank-padded for purposes of
comparison (but saying that blanks are trimmed or ignored for that
purpose is also technically correct), it is definitely not padded in
other contexts, neither for concatenation, where not padding or
trimming occurs at all, nor for length evaluation, where blanks are
trimmed or ignored.

> So bpchar(n) is automatically blank padded to a total length for a value of n characters. bpchar also has padding blanks but they must be manually inserted during value creation.

BPCHAR(n) is definitely blank-padded to n, no doubt. BPCHAR may have
trailing blanks, if and only if they are added manually. But the
ability to store trailing blanks is not the same as blank-padding.
Manual addition is not padding, If it were, then VARCHAR would also be
"blank-padded", because you can manually add trailing blanks to values
of this type too. But of course it isn't.

> I would leave the note of blank-padded for both and just point out the automatic vs manual distinction.

The current wording in Table 8.4 is that BPCHAR is blank-trimmed, not
blank-padded anyway.

With best regards,
Sergei Katkovskii