Re: BPCHAR description in 8.3. Character Types is misleading and incomplete

On Fri, 2025-10-17 at 18:18 +0400, Sergei Katkovsky wrote:
> On Fri, Oct 17, 2025 at 4:49 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> > "bpchar" and "varchar", when used without type modifier, are actually
> > identical:
> >
> > SELECT octet_length(BPCHAR 'x   '),
> >         octet_length(VARCHAR 'x   '),
> >         octet_length(TEXT 'x   ');
> >
> >   octet_length │ octet_length │ octet_length
> > ══════════════╪══════════════╪══════════════
> >              4 │            4 │            4
> >
> > The blank-trimming only occurs when a "bpchar" is converted to "text",
> > for example when used with the concatenation operator.
>
> Unfortunately, BPCHAR and VARCHAR are not identical in other contexts.
> The situation is not the same as with BCHAR(n), which is just an alias
> for CHAR(n).
> SELECT BPCHAR 'x' = VARCHAR 'x   ', VARCHAR 'x' = BPCHAR 'x   ',
> VARCHAR 'x' = VARCHAR 'x   ';
> true true false
> For comparison with BPCHAR trailing blanks are insignificant, but when
> we have VARCHAR on both sides, they matter.

They are stored identically, but behave differently, so I shouldn't have
said that they *are* identical.

Still, they all are variable-length strings, so we could list them together.

But perhaps it is really better to leave things as they are now, perhaps
replacing "blank-trimming", perhaps as "variable-length string that ignores
training blanks".

Yours,
Laurenz Albe