Re: BUG #17258: Unexpected results in CHAR(1) data type - Mailing list pgsql-bugs

From Mark Dilger
Subject Re: BUG #17258: Unexpected results in CHAR(1) data type
Date
Msg-id B7220689-0307-46C5-A65D-3BD60DA364B4@enterprisedb.com
Whole thread Raw
In response to Re: BUG #17258: Unexpected results in CHAR(1) data type  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs

> On Oct 29, 2021, at 3:13 PM, David G. Johnston <david.g.johnston@gmail.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
possiblefor 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
expectCHAR(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
insteadchoose a different datatype (which you also said.) 


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type
Next
From: Andres Freund
Date:
Subject: Re: BUG #17245: Index corruption involving deduplicated entries