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>
In-Reply-To: 
 <CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com>
From: Sergei Katkovsky <skatkovsky@gmail.com>
Date: Thu, 16 Oct 2025 18:19:51 +0400
Message-ID: 
 <CAAf8JyLQp-u+nToXQZBasTHg4mj8YuWvX2bPkt_rvrDfHiW0qg@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/CAAf8JyLQp-u%2BnToXQZBasTHg4mj8YuWvX2bPkt_rvrDfHiW0qg%40mail.gmail.com>
Precedence: bulk

On Thu, Oct 16, 2025 at 4:36=E2=80=AFPM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> A given value has a finite length and there is just no restriction on wha=
t that length is.  All trailing spaces in the input are considered padding =
for purposes of comparison i.e., manually padding is added by the user as o=
pposed to the system.

A given value of BPCHAR is stored as is, without padding or trimming
(contrary to the current wording in Table 8.4 about black-trimming).
But what is the point of saying that it is manually padded, if the
user is free to store it without any padding? And, although
technically you can say that BPCHAR is blank-padded for purposes of
comparison (but saying that blanks are trimmed or ignored for that
purpose is also technically correct), it is definitely not padded in
other contexts, neither for concatenation, where not padding or
trimming occurs at all, nor for length evaluation, where blanks are
trimmed or ignored.

> So bpchar(n) is automatically blank padded to a total length for a value =
of n characters.  bpchar also has padding blanks but they must be manually =
inserted during value creation.

BPCHAR(n) is definitely blank-padded to n, no doubt. BPCHAR may have
trailing blanks, if and only if they are added manually. But the
ability to store trailing blanks is not the same as blank-padding.
Manual addition is not padding, If it were, then VARCHAR would also be
"blank-padded", because you can manually add trailing blanks to values
of this type too. But of course it isn't.

> I would leave the note of blank-padded for both and just point out the au=
tomatic vs manual distinction.

The current wording in Table 8.4 is that BPCHAR is blank-trimmed, not
blank-padded anyway.

With best regards,
Sergei Katkovskii