Re: BUG #17258: Unexpected results in CHAR(1) data type

> On Oct 29, 2021, at 12:32 PM, David M. Calascibetta <david(at)calascibetta(dot)com> wrote:
>
> Ok, but my example was just a simplified version of what is going on.
> The actual problem stems from a CHAR(1) column data type that is behaving the same way.
> I was just trying to create a super-simple example of the problem.
> It still seems to me that a CHAR(1) should never be zero length, regardless of how it's implemented.

Please consider:

mark.dilger=# select ''::char(1) = ' '::char(50);
?column?
----------
t
(1 row)

I infer that you expect a single byte of space to be compared against 50 bytes of space, and to be found unequal. Postgres doesn't treat trailing spaces in char(n) the way I infer that you expect. Even without casting to another type (and the equality operator for char(n) does not cast to another type) the comparison logic intentionally ignores the trailing spaces.

Consider also:

mark.dilger=# select length(' '::char(50));
length
--------
0
(1 row)

Perhaps this behavior is nuts, but I say it is not a bug, just a peculiarity in how char(n) is defined to behave.

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