public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sergei Katkovsky <[email protected]>
To: David G. Johnston <[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 23:00:04 +0400
Message-ID: <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwbfQ_uP+vot0ys_wo4cS6ZCpn=aZxhVGZ-tt_4HB7CVHw@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>
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. The value 'abc'::bpchar does not
contain any blanks. But it's still a BPCHAR value. And it is not
padded, despite that its type is BPCHAR.
> And yes, this is intended as a way to make the name of the type and its behavior consistent.
The behavior of 'abc'::BPCHAR is, for example, the following:
length('abc'::BPCHAR) = 3
CONCAT('abc::BPCHAR, 'def') = 'abcdef'.
What of the above is consistent with the notion of being 'blank-padded'?
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.
> You sorta have to want it to work/make sense; not fight it on minor nuance.
The sole reason that I am here is that recently I came across a
(year-old) question on stackoverflow where some person was curious why
the actual behavior of BPCHAR was inconsistent with the documentation.
What is worse is that the question was answered, but answered
incorrectly. So, I doubt that it is just a minor nuance. Probably, not
just one person tried to use BPCHAR as a 'blank-trimming' type.
With best regards,
Sergei Katkovskii
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: <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@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