MIME-Version: 1.0
References: <176044409338.770.16064383081308443747@wrigleys.postgresql.org>
 <e9ad2cb03195402a96e8cb9130470bfca3bf49c7.camel@j-davis.com>
 <1307875.1760556576@sss.pgh.pa.us>
 <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>
In-Reply-To: 
 <CAKFQuwbfQ_uP+vot0ys_wo4cS6ZCpn=aZxhVGZ-tt_4HB7CVHw@mail.gmail.com>
From: Sergei Katkovsky <skatkovsky@gmail.com>
Date: Thu, 16 Oct 2025 23:00:04 +0400
Message-ID: 
 <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@mail.gmail.com>
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and
 incomplete
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>,
	"pgsql-docs@lists.postgresql.org" <pgsql-docs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn%2BLw%40mail.gmail.com>
Precedence: bulk

On Thu, Oct 16, 2025 at 10:11=E2=80=AFPM David G. Johnston
<david.g.johnston@gmail.com> wrote:

> The spaces added to the end of a bpchar manually can and are considered =
=E2=80=9Cpadding=E2=80=9D - or =E2=80=9Cpresent but lack semantic/value sig=
nificance=E2=80=9D. The reason they are not padding for varchar is that suc=
h spaces are considered part of the stored value from a semantic perspectiv=
e.
>
> Think of padding as a noun, not a verb.  =E2=80=9CThe value contains padd=
ing=E2=80=9D.  Not, =E2=80=9C I am padding the value=E2=80=9D.

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 b=
ehavior consistent.

The behavior of 'abc'::BPCHAR is, for example, the following:
length('abc'::BPCHAR) =3D 3
CONCAT('abc::BPCHAR, 'def') =3D '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 nuanc=
e.

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