MIME-Version: 1.0
In-Reply-To: 
 <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@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>
 <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>
From: "David G. Johnston" <david.g.johnston@gmail.com>
Date: Thu, 16 Oct 2025 15:18:52 -0400
Message-ID: 
 <CAKFQuwaRmF6yznCwcjYzBP=L1BMWxAc2=Kr=C3kEuTbxw2jD-w@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="000000000000e0d42206414b7c85"
Archived-At: 
 <https://www.postgresql.org/message-id/CAKFQuwaRmF6yznCwcjYzBP%3DL1BMWxAc2%3DKr%3DC3kEuTbxw2jD-w%40mail.gmail.com>
Precedence: bulk

--000000000000e0d42206414b7c85
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

> 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 s=
ignificance=E2=80=9D. 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.  =E2=80=9CThe value contains pa=
dding=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.


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=E2=80=99m on board with that.  Blank-padded is IMO the best =E2=80=9Cmore=
 appropriate=E2=80=9D
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.

--000000000000e0d42206414b7c85
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">On Thu, Oct 16, 2025 at 10:11=E2=80=AFPM David G. Johnston<br=
>
&lt;<a href=3D"mailto:david.g.johnston@gmail.com">david.g.johnston@gmail.co=
m</a>&gt; wrote:<br>
<br>
&gt; The spaces added to the end of a bpchar manually can and are considere=
d =E2=80=9Cpadding=E2=80=9D - or =E2=80=9Cpresent but lack semantic/value s=
ignificance=E2=80=9D. The reason they are not padding for varchar is that s=
uch spaces are considered part of the stored value from a semantic perspect=
ive.<br>
&gt;<br>
&gt; Think of padding as a noun, not a verb.=C2=A0 =E2=80=9CThe value conta=
ins padding=E2=80=9D.=C2=A0 Not, =E2=80=9C I am padding the value=E2=80=9D.=
<br>
<br>
The value may sometimes contain padding. And sometimes not.=C2=A0</blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">But we are<br>
talking about the type, not value.</blockquote><div><br></div><div>We are t=
alking about the properties of values stored within the type and the behavi=
or during their construction and use.=C2=A0 For bpchar those values have no=
 length limitation and any trailing spaces present are considered padding.<=
/div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And, the proposal is not to change the name of the type. The proposal<br>
is to change the wording &#39;blank-trimming&#39; to something more<br>
appropriate.</blockquote><div><br></div><div>I=E2=80=99m on board with that=
.=C2=A0 Blank-padded is IMO the best =E2=80=9Cmore appropriate=E2=80=9D cho=
ice.</div><div><br></div><div>In PostgreSQL the behavior and stored content=
s/representation of a value are not influenced by a type modifier.=C2=A0 It=
 is only used during input to perform some either or both a validation or t=
ransformation.=C2=A0 Here, when present, it performs a padding transform.=
=C2=A0 But present or absent, trailing spaces, if any, are considered paddi=
ng.=C2=A0 The prose for the section talk about the two key pieces: (n) impo=
ses a length limit while also transforming an input by adding padding space=
s.=C2=A0 The non-n case has unlimited length and no transformation.=C2=A0 P=
ost-construction, all trailing spaces are treated as padding.</div><div><br=
></div><div>David J.</div><div><br></div>

--000000000000e0d42206414b7c85--