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

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(dot)dilger(at)enterprisedb(dot)com>
Sent: Friday, October 29, 2021 4:16 PM
To: <David(at)calascibetta(dot)com> <David(at)Calascibetta(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: 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