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>
 <CAAf8JyL4xYd4qFD5_5x9hF03L=xjkx6sXHOU8DhU8Y_f7FBw5A@mail.gmail.com>
 <CAKFQuwbqcQY=H9YRs=bJ4m4kvXu19hBNKVhu992_cUvpcUTzvQ@mail.gmail.com>
In-Reply-To: 
 <CAKFQuwbqcQY=H9YRs=bJ4m4kvXu19hBNKVhu992_cUvpcUTzvQ@mail.gmail.com>
From: Sergei Katkovsky <skatkovsky@gmail.com>
Date: Fri, 17 Oct 2025 11:37:40 +0400
Message-ID: 
 <CAAf8Jy+49UAExghnssRR4oACSVGk7HejrU7GipdijWWBsbPt4Q@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/CAAf8Jy%2B49UAExghnssRR4oACSVGk7HejrU7GipdijWWBsbPt4Q%40mail.gmail.com>
Precedence: bulk

On Fri, Oct 17, 2025 at 1:08=E2=80=AFAM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
>
> I=E2=80=99m just trying to phrase the documentation for bpchar so that th=
e =E2=80=9Cbp=E2=80=9D, which stands for =E2=80=9Cblank-padded=E2=80=9D, is=
 justified.

That's what I thought. Yes, unfortunately, bp stands for
=E2=80=9Cblank-padded=E2=80=9D, but this name is wrong and misleading. I do=
n't know
why it was chosen, maybe it was actually considered as blank-padded at
that time, maybe it was an attempt to avoid introducing a new keyword
(an ancient curse that has ruined a lot of good ideas already). It
doesn't matter, though. That was a mistake in my opinion, but we don't
have to repeat it. There is no need to justify wrongs. An honest
remark (footnote, tip, whatever) in documentation "Although BP in
BPCHAR stands for 'blank-padded', no padding is actually performed for
this type" would be far better.

>
> I do understand the terminology confusion with the verb padding.  And see=
 why =E2=80=9Ctrimmed=E2=80=9D is actively confusing.  The prose probably n=
eeds to resolve this - and technically does from what I=E2=80=99m reading.
>
> You may wish to move on from critiquing my suggested changes and instead =
propose something concrete of your own.  Provide a third choice besides sta=
tus-quo and my option.

I already did this. It was my original request that started this
discussion, and I suggested there, although more as a guide,
"as-if-blank-trimmed" and "blank-ignoring". But then Jeff Davis
prepared a patch and proposed "blank-insignificant" instead, which I
support now (after that, I also suggested "blank-agnostic", but that
was more of a joke). So, the third choice already exists, and there is
even a patch implementing it.

Of course, "blank-insignificant" is not perfect either, specifically,
it's not immediately obvious that only trailing blanks are
insignificant here. Perhaps a better term would be
"trailing-blanks-insignificant", with or without hyphens. But in my
opinion. both are much more appropriate and less misleading than
either "blank-padded" or "blank-trimmed".

>
> Though I=E2=80=99m doubtful there is a nice precise hyphenated word to be=
 found here for =E2=80=9Ctreats any trailing spaces as being semantically i=
nsignificant=E2=80=9D.

Yes, but nobody requires us to use such a word here. We can use a few
more words if needed.


With best regards,
Sergei Katkovskii