MIME-Version: 1.0
In-Reply-To: 
 <CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg@mail.gmail.com>
References: <176044409338.770.16064383081308443747@wrigleys.postgresql.org>
 <e9ad2cb03195402a96e8cb9130470bfca3bf49c7.camel@j-davis.com>
 <1307875.1760556576@sss.pgh.pa.us>
 <CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg@mail.gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Thu, 16 Oct 2025 08:36:50 -0400
Message-ID: 
 <CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com>
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and
 incomplete
To: Sergei Katkovsky <skatkovsky@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: multipart/alternative; boundary="0000000000001c87d4064145dfe9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw%40mail.gmail.com>
Precedence: bulk

--0000000000001c87d4064145dfe9
Content-Type: text/plain; charset="UTF-8"

On Thursday, October 16, 2025, Sergei Katkovsky <skatkovsky@gmail.com>
wrote:

> > I don't understand why any of these variants are better than the
> > original wording "blank-padded".  That has the non-negligible
> > advantage of corresponding to the type name, and furthermore
> > appears in many other places in our docs and source code.
>
> The wording for BPCHAR (not to be confused with BPCHAR(N) is already
> "blank-trimming", not "blank-padded". And "blank-padded" is probably
> the least correct wording variant for BPCHAR, because this type has
> unlimited length and it's impossible to pad to the infinity.


A given value has a finite length and there is just no restriction on what
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
opposed to the system.

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.

I would leave the note of blank-padded for both and just point out the
automatic vs manual distinction.

David J.

--0000000000001c87d4064145dfe9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thursday, October 16, 2025, Sergei Katkovsky &lt;<a href=3D"mailto:skatk=
ovsky@gmail.com">skatkovsky@gmail.com</a>&gt; wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">&gt; I don&#39;t understand why any of these variants are bet=
ter than the<br>
&gt; original wording &quot;blank-padded&quot;.=C2=A0 That has the non-negl=
igible<br>
&gt; advantage of corresponding to the type name, and furthermore<br>
&gt; appears in many other places in our docs and source code.<br>
<br>
The wording for BPCHAR (not to be confused with BPCHAR(N) is already<br>
&quot;blank-trimming&quot;, not &quot;blank-padded&quot;. And &quot;blank-p=
added&quot; is probably<br>
the least correct wording variant for BPCHAR, because this type has<br>
unlimited length and it&#39;s impossible to pad to the infinity.</blockquot=
e><div><br></div><div>A given value has a finite length and there is just n=
o restriction on what that length is.=C2=A0 All trailing spaces in the inpu=
t are considered padding for purposes of comparison i.e., manually padding =
is added by the user as opposed to the system.</div><div><br></div><div>So =
bpchar(n) is automatically blank padded to a total length for a value of n =
characters. =C2=A0bpchar also has padding blanks but they must be manually =
inserted during value creation.</div><div><br></div><div>I would leave the =
note of blank-padded for both and just point out the automatic vs manual di=
stinction.</div><div><br></div><div>David J.</div><div><br></div>

--0000000000001c87d4064145dfe9--