On Thu, Oct 16, 2025 at 10:11 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
> The spaces added to the end of a bpchar manually can and are considered “padding” - or “present but lack
semantic/valuesignificance”. The reason they are not padding for varchar is that such spaces are considered part of the
storedvalue from a semantic perspective.
>
> Think of padding as a noun, not a verb. “The value contains padding”. Not, “ I am padding the value”.
The value may sometimes contain padding. And sometimes not. But we are
talking about the type, not value. The value 'abc'::bpchar does not
contain any blanks. But it's still a BPCHAR value. And it is not
padded, despite that its type is BPCHAR.
> And yes, this is intended as a way to make the name of the type and its behavior consistent.
The behavior of 'abc'::BPCHAR is, for example, the following:
length('abc'::BPCHAR) = 3
CONCAT('abc::BPCHAR, 'def') = 'abcdef'.
What of the above is consistent with the notion of being 'blank-padded'?
And, the proposal is not to change the name of the type. The proposal
is to change the wording 'blank-trimming' to something more
appropriate.
> You sorta have to want it to work/make sense; not fight it on minor nuance.
The sole reason that I am here is that recently I came across a
(year-old) question on stackoverflow where some person was curious why
the actual behavior of BPCHAR was inconsistent with the documentation.
What is worse is that the question was answered, but answered
incorrectly. So, I doubt that it is just a minor nuance. Probably, not
just one person tried to use BPCHAR as a 'blank-trimming' type.
With best regards,
Sergei Katkovskii
