"Ian R. Campbell" <ian.campbell@thepathcentral.com> writes: > I noticed that the following does not produce consistent cast results: > select 1::int8::"char", 1::int4::"char", 1::int2::"char"
The reason for this is that there's a bespoke int4-to-"char" cast, which just produces the character with that code point; this is documented as the "char"(int) function. However, there are no such bespoke casts for int2 or int8, so those go via cast-via-I/O, much as if you were casting to/from text. The same happens with numeric, or indeed other types.
One possible answer to this is to reclassify "char" as not being a member of the "string" category, so that the implicit-I/O-cast rule wouldn't be applied to it. I'm not sure if that'd have any downsides, but it seems like in principle it might be all right. "char" is so restricted that treating it as a general- purpose string type doesn't seem very sane.
(Now that I look, I see that somebody thought that it'd be cool to assign category S to various special-purpose types like pg_mcv_list. That seems downright dangerous.)