| 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: | BPCHAR description in 8.3. Character Types is misleading and incomplete |
| Date: | 2025-10-16 18:11:10 |
| Message-ID: | CAKFQuwbfQ_uP+vot0ys_wo4cS6ZCpn=aZxhVGZ-tt_4HB7CVHw@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:
> 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.
>
The spaces added to the end of a bpchar manually can and are considered
“padding” - or “present but lack semantic/value significance”. The reason
they are not padding for varchar is that such spaces are considered part of
the stored value from a semantic perspective.
Think of padding as a noun, not a verb. “The value contains padding”.
Not, “ I am padding the value”.
And yes, this is intended as a way to make the name of the type and its
behavior consistent. You sorta have to want it to work/make sense; not
fight it on minor nuance.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2025-10-16 18:40:36 | Re: BPCHAR description in 8.3. Character Types is misleading and incomplete |
| Previous Message | Jeff Davis | 2025-10-16 15:21:16 | Re: BPCHAR description in 8.3. Character Types is misleading and incomplete |