From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Ian R. Campbell" <ian.campbell@thepathcentral.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Inconsistent cast to "char"
In-reply-to: 
 <CAOC8YUfU9Ry_1oGoQ804aE3kZP8jBJ6+wXbhBkK1y6c547UPig@mail.gmail.com>
References: 
 <CAOC8YUcXymCMpC5d=7JvcwyjXPTT00WeebOM3UqTBreOD1N9hw@mail.gmail.com>
 <2117701.1638471036@sss.pgh.pa.us>
 <CAOC8YUfU9Ry_1oGoQ804aE3kZP8jBJ6+wXbhBkK1y6c547UPig@mail.gmail.com>
Comments: In-reply-to "Ian R. Campbell" <ian.campbell@thepathcentral.com>
	message dated "Thu, 02 Dec 2021 20:53:55 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2120115.1638473263.1@sss.pgh.pa.us>
Date: Thu, 02 Dec 2021 14:27:43 -0500
Message-ID: <2120116.1638473263@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2120116.1638473263%40sss.pgh.pa.us>
Precedence: bulk

"Ian R. Campbell" <ian.campbell@thepathcentral.com> writes:
> It makes sense that "char" is not part of the string family. After all,
> "char" != char.

If it allowed more than one byte, maybe you could call it a "string",
but it seems hard to justify without that.

> In the scenarios I give, one would expect the same output for all integer
> width casting inputs, so you have my vote on the change you suggested.

To be clear, the change I'm thinking of would result in errors, not in
silently applying the int4 cast.  As a quick-n-dirty test:

regression=# update pg_type set typcategory = 'x' where typname = 'char';
UPDATE 1
regression=# select 1::int8::"char", 1::int4::"char", 1::int2::"char";
ERROR:  cannot cast type bigint to "char"
LINE 1: select 1::int8::"char", 1::int4::"char", 1::int2::"char";
                      ^

			regards, tom lane