public inbox for [email protected]
help / color / mirror / Atom feedFrom: David G. Johnston <[email protected]>
To: Sergei Katkovsky <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and incomplete
Date: Thu, 16 Oct 2025 15:18:52 -0400
Message-ID: <CAKFQuwaRmF6yznCwcjYzBP=L1BMWxAc2=Kr=C3kEuTbxw2jD-w@mail.gmail.com> (raw)
In-Reply-To: <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg@mail.gmail.com>
<CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com>
<CAAf8JyLQp-u+nToXQZBasTHg4mj8YuWvX2bPkt_rvrDfHiW0qg@mail.gmail.com>
<CAKFQuwbfQ_uP+vot0ys_wo4cS6ZCpn=aZxhVGZ-tt_4HB7CVHw@mail.gmail.com>
<CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@mail.gmail.com>
On Thursday, October 16, 2025, Sergei Katkovsky <[email protected]>
wrote:
> On Thu, Oct 16, 2025 at 10:11 PM David G. Johnston
> <[email protected]> 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.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and incomplete
In-Reply-To: <CAKFQuwaRmF6yznCwcjYzBP=L1BMWxAc2=Kr=C3kEuTbxw2jD-w@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox