| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Sergei Katkovsky <skatkovsky(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeff Davis <pgsql(at)j-davis(dot)com>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BPCHAR description in 8.3. Character Types is misleading and incomplete |
| Date: | 2025-10-16 12:36:50 |
| Message-ID: | CAKFQuwZJhDgg_WqWq7HMAUd7bGiU4r-VFVXn72Hfq9VQhRKZMw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
On Thursday, October 16, 2025, Sergei Katkovsky <skatkovsky(at)gmail(dot)com>
wrote:
> > I don't understand why any of these variants are better than the
> > original wording "blank-padded". That has the non-negligible
> > advantage of corresponding to the type name, and furthermore
> > appears in many other places in our docs and source code.
>
> The wording for BPCHAR (not to be confused with BPCHAR(N) is already
> "blank-trimming", not "blank-padded". And "blank-padded" is probably
> the least correct wording variant for BPCHAR, because this type has
> unlimited length and it's impossible to pad to the infinity.
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.
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.
I would leave the note of blank-padded for both and just point out the
automatic vs manual distinction.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Doc comments form | 2025-10-16 13:23:51 | Can not close psql |
| Previous Message | Erik Wienhold | 2025-10-16 08:37:37 | Use uppercase keywords in foreign key tutorial |