> 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
