On Thu, Oct 16, 2025 at 11:18 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>> > Think of padding as a noun, not a verb. “The value contains padding”. Not, “ I am padding the value”.
>
> In PostgreSQL the behavior and stored contents/representation of a value are not influenced by a type modifier. It
isonly used during input to perform some either or both a validation or transformation. Here, when present, it
performsa padding transform. But present or absent, trailing spaces, if any, are considered padding. The prose for
thesection talk about the two key pieces: (n) imposes a length limit while also transforming an input by adding padding
spaces. The non-n case has unlimited length and no transformation. Post-construction, all trailing spaces are treated
aspadding.
Am I right that your reasoning, when expanded, turns into "BPCHAR is
blank-padded, where '-padded' means (Definition 1) that its values may
have trailing blanks, which, if present, are considered 'padding'
(Definition 2), which, in its turn, means a sequence of blanks
insignificant in some contexts (Definition 3)"? Yes, technically it is
correct, provided that others accept all those definitions. But don't
you think that in the documentation we should, whenever possible, use
words in their most commonly understood meanings? I'm not a language
expert, but I have never seen 'padded' in the sense different from
'something added to gain some needed size/shape/etc'. This is
anecdotal evidence, of course, so I can be wrong, but could you come
up with a counterexample? Even in the PostgreSQL docs for BPCHAR(n)
'padded' means 'with spaces added up to n' ('values of type character
will be space-padded', 'Values of type character are physically padded
with spaces' - as a verb, not a noun, btw). I'm afraid that adding
another meaning to the word 'padded' in the same text will cause even
more confusion.
With best regards,
Sergei Katkovskii
