public inbox for [email protected]  

help / color / mirror / Atom feed

From: Sergei Katkovsky <[email protected]>
To: David G. Johnston <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Jeff Davis <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: BPCHAR description in 8.3. Character Types is misleading and incomplete
Date: Thu, 16 Oct 2025 18:19:51 +0400
Message-ID: <CAAf8JyLQp-u+nToXQZBasTHg4mj8YuWvX2bPkt_rvrDfHiW0qg@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<CAAf8JyJNWf9BrpBJNpqEwTM7orbR48XenoALAE8icA68kaC5Wg@mail.gmail.com>
	<CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com>

On Thu, Oct 16, 2025 at 4:36 PM David G. Johnston
<[email protected]> wrote:
>
> 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.

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 automatic 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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: BPCHAR description in 8.3. Character Types is misleading and incomplete
  In-Reply-To: <CAAf8JyLQp-u+nToXQZBasTHg4mj8YuWvX2bPkt_rvrDfHiW0qg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox