Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Subject: Re: The same result for with SPACE and without SPACE
From: Scott Ribe <scott_ribe@elevated-dev.com>
In-Reply-To: 
 <DM4PR19MB59784B518F25D2C2292CA3FBD35AA@DM4PR19MB5978.namprd19.prod.outlook.com>
Date: Wed, 14 Jun 2023 16:47:21 -0600
Cc: "pgsql-admin@lists.postgresql.org" <pgsql-admin@lists.postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9358F9A5-2926-4046-AD48-0C83C790A523@elevated-dev.com>
References: 
 <DM4PR19MB5978EB964FA1C7B55FFCB02DD35AA@DM4PR19MB5978.namprd19.prod.outlook.com>
 <DM4PR19MB59782360E0C452810D70CBE8D35AA@DM4PR19MB5978.namprd19.prod.outlook.com>
 <B600CCAA-59E5-4907-8E6D-C645CA24AB1D@elevated-dev.com>
 <DM4PR19MB59784B518F25D2C2292CA3FBD35AA@DM4PR19MB5978.namprd19.prod.outlook.com>
To: M Sarwar <sarwarmd02@outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/9358F9A5-2926-4046-AD48-0C83C790A523%40elevated-dev.com>
Precedence: bulk

> On Jun 14, 2023, at 4:31 PM, M Sarwar <sarwarmd02@outlook.com> wrote:
>=20
> I expect this to behave the same way whether it comes from CHAR or =
VARCHAR.

Why would you expect that??? CHAR explicitly means that:

1) shorter strings will be space-padded to the given length
2) if a string is presented with spaces making it longer, it will be =
truncated

Putting it all together, it implies:

3) trailing spaces are semantically meaningless

Anyway, the closest I could to finding a reference on comparison =
behavior for this case states: "The ANSI standard requires padding for =
the character strings used in comparisons so that their lengths match =
before comparing them."

And there you go, you used CHAR(10), so all values in the table are =
space-padded to length 10, so for comparison *any* value will be =
space-padded to 10.