On Fri, 2025-10-17 at 18:18 +0400, Sergei Katkovsky wrote: > On Fri, Oct 17, 2025 at 4:49 PM Laurenz Albe <[email protected]> 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
