From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Ian R(dot) Campbell" <ian(dot)campbell(at)thepathcentral(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Inconsistent cast to "char" |
Date: | 2021-12-02 19:27:43 |
Message-ID: | 2120116.1638473263@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Ian R. Campbell" <ian(dot)campbell(at)thepathcentral(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-12-02 21:31:23 | Re: Inconsistent cast to "char" |
Previous Message | Tom Lane | 2021-12-02 18:54:15 | Re: BUG #17305: to_timestamp accept dates rejected by timestamptz cast |