Re: Inconsistent cast to "char"

It makes sense that "char" is not part of the string family. After all,
"char" != char.

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.

On Thu, 2 Dec 2021 at 20:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "Ian R. Campbell" <ian(dot)campbell(at)thepathcentral(dot)com> writes:
> > I noticed that the following does not produce consistent cast results:
> > select 1::int8::"char", 1::int4::"char", 1::int2::"char"
>
> Concretely, that gives:
>
> regression=# select 1::int8::"char", 1::int4::"char", 1::int2::"char";
> char | char | char
> ------+------+------
> 1 | \x01 | 1
> (1 row)
>
> 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.)
>
> regards, tom lane
>