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"
Date: Thu, 02 Dec 2021 14:27:43 -0500
Message-ID: <2120116.1638473263@sss.pgh.pa.us> (raw)
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>
"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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, ian.campbell@thepathcentral.com, pgsql-bugs@lists.postgresql.org
Subject: Re: Inconsistent cast to "char"
In-Reply-To: <2120116.1638473263@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox