OK. I have a work-around so I'm alright.
I agree, the behavior is nuts, and is inconsistent with every other RDBMS out there.
I was only reporting it to improve the product, but if you think this is appropriate behavior,
I'm good with it. You can close this issue.
David
-----Original Message-----
From: Mark Dilger <mark.dilger@enterprisedb.com>
Sent: Friday, October 29, 2021 4:16 PM
To: <David@calascibetta.com> <David@Calascibetta.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17258: Unexpected results in CHAR(1) data type
> 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