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>
 <CAAf8JyK7qVbCw0Lrk3NCCe9zgnt5856zjBULetA9zP13hGn+Lw@mail.gmail.com>
 <CAKFQuwaRmF6yznCwcjYzBP=L1BMWxAc2=Kr=C3kEuTbxw2jD-w@mail.gmail.com>
In-Reply-To: 
 <CAKFQuwaRmF6yznCwcjYzBP=L1BMWxAc2=Kr=C3kEuTbxw2jD-w@mail.gmail.com>
From: Sergei Katkovsky <skatkovsky@gmail.com>
Date: Fri, 17 Oct 2025 00:41:37 +0400
Message-ID: 
 <CAAf8JyL4xYd4qFD5_5x9hF03L=xjkx6sXHOU8DhU8Y_f7FBw5A@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/CAAf8JyL4xYd4qFD5_5x9hF03L%3Dxjkx6sXHOU8DhU8Y_f7FBw5A%40mail.gmail.com>
Precedence: bulk

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

>> > Think of padding as a noun, not a verb.  =E2=80=9CThe value contains p=
adding=E2=80=9D.  Not, =E2=80=9C I am padding the value=E2=80=9D.
>
> 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 per=
form some either or both a validation or transformation.  Here, when presen=
t, 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 inpu=
t by adding padding spaces.  The non-n case has unlimited length and no tra=
nsformation.  Post-construction, all trailing spaces are treated as padding=
.

Am I right that your reasoning, when expanded, turns into "BPCHAR is
blank-padded, where '-padded' means (Definition 1) that its values may
have trailing blanks, which, if present, are considered 'padding'
(Definition 2), which, in its turn, means a sequence of blanks
insignificant in some contexts (Definition 3)"? Yes, technically it is
correct, provided that others accept all those definitions. But don't
you think that in the documentation we should, whenever possible, use
words in their most commonly understood meanings? I'm not a language
expert, but I have never seen 'padded' in the sense different from
'something added to gain some needed size/shape/etc'. This is
anecdotal evidence, of course, so I can be wrong, but could you come
up with a counterexample?  Even in the PostgreSQL docs for BPCHAR(n)
'padded' means 'with spaces added up to n' ('values of type character
will be space-padded', 'Values of type character are physically padded
with spaces' - as a verb, not a noun, btw). I'm afraid that adding
another meaning to the word 'padded' in the same text will cause even
more confusion.


With best regards,
Sergei Katkovskii