> On Oct 29, 2021, at 12:32 PM, David M. Calascibetta <david@calascibetta.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.
Postgresdoesn't treat trailing spaces in char(n) the way I infer that you expect. Even without casting to another type
(andthe equality operator for char(n) does not cast to another type) the comparison logic intentionally ignores the
trailingspaces.
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