From: David M. Calascibetta <david@calascibetta.com>
To: 'Mark Dilger' <mark.dilger@enterprisedb.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type
Date: Fri, 29 Oct 2021 16:26:15 -0500
Message-ID: <005501d7cd0b$9ba5d5f0$d2f181d0$@calascibetta.com> (raw)
In-Reply-To: <0EE9669C-6E65-40E1-B492-F989F452DAC4@enterprisedb.com>
References: <17258-a7c164c5fb955221@postgresql.org>
<19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com>
<003701d7ccfb$c2a85bb0$47f91310$@calascibetta.com>
<0EE9669C-6E65-40E1-B492-F989F452DAC4@enterprisedb.com>
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. 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: david@calascibetta.com, mark.dilger@enterprisedb.com, pgsql-bugs@lists.postgresql.org
Subject: RE: BUG #17258: Unexpected results in CHAR(1) data type
In-Reply-To: <005501d7cd0b$9ba5d5f0$d2f181d0$@calascibetta.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox