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

On Thursday, October 16, 2025, Sergei Katkovsky <skatkovsky(at)gmail(dot)com>
wrote:

> On Thu, Oct 16, 2025 at 10:11 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> > The spaces added to the end of a bpchar manually can and are considered
> “padding” - or “present but lack semantic/value significance”. The reason
> they are not padding for varchar is that such spaces are considered part of
> the stored value 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.

We are talking about the properties of values stored within the type and
the behavior during their construction and use. For bpchar those values
have no length limitation and any trailing spaces present are considered
padding.

> 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.

I’m on board with that. Blank-padded is IMO the best “more appropriate”
choice.

In PostgreSQL the behavior and stored contents/representation of a value
are not influenced by a type modifier. It is only used during input to
perform some either or both a validation or transformation. Here, when
present, it performs a padding transform. But present or absent, trailing
spaces, if any, are considered padding. The prose for the section 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 as padding.

David J.