| From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | "<David(at)calascibetta(dot)com>" <David(at)calascibetta(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #17258: Unexpected results in CHAR(1) data type |
| Date: | 2021-10-29 22:18:30 |
| Message-ID: | B7220689-0307-46C5-A65D-3BD60DA364B4@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On Oct 29, 2021, at 3:13 PM, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>
> For practical purposes you will frequently hit the one bit or the other.
>
>
> As I noted in a prior reply, octet_length(char) does the length computation with the padding spaces. So it is possible for char input functions to do the expected thing.
Yes, I saw that. But there aren't that many functions like octet_length that do so. If users coming from other RDBMSs expect CHAR(1) to behave as David expects them to behave, it's cold comfort to say, "hang in there, you can still use octet_length() on them!" Better to say that they are going to be bitten by this expectation again and again, and instead choose a different datatype (which you also said.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2021-10-29 22:22:42 | Re: BUG #17245: Index corruption involving deduplicated entries |
| Previous Message | David G. Johnston | 2021-10-29 22:13:08 | Re: BUG #17258: Unexpected results in CHAR(1) data type |