On Thursday, October 16, 2025, Sergei Katkovsky <
skatkovsky@gmail.com> wrote:
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/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.
