Feedback-ID: david@calascibe
Reply-To: <David@Calascibetta.com>
From: "David M. Calascibetta" <david@calascibetta.com>
To: "'Mark Dilger'" <mark.dilger@enterprisedb.com>
Cc: <pgsql-bugs@lists.postgresql.org>
References: <17258-a7c164c5fb955221@postgresql.org>
 <19D58355-E7C3-47D7-9C87-51EC751AE2BB@enterprisedb.com>
 <003701d7ccfb$c2a85bb0$47f91310$@calascibetta.com>
 <0EE9669C-6E65-40E1-B492-F989F452DAC4@enterprisedb.com>
In-Reply-To: <0EE9669C-6E65-40E1-B492-F989F452DAC4@enterprisedb.com>
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>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLB1uYWs1aJVPkX1BZhIF63SkMLgwH/iU5GAnFecvcC9n3sD6nbLbYQ
Content-Language: en-us
Archived-At: 
 <https://www.postgresql.org/message-id/005501d7cd0b%249ba5d5f0%24d2f181d0%24%40calascibetta.com>
Precedence: bulk

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>=20
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:
>=20
> 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=3D# select ''::char(1) =3D '               '::char(50);
 ?column?=20
----------
 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=3D# 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.=20


=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL =
Company