Sam Mason <sam@samason.me.uk> wrote:
> I fail to see how an error isn't the right thing; if we try with
> some other types let see if you think any of these should succeed.
>
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE 0 END;
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE TRUE END;
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE '{1}'::INT[] END;
> SELECT CASE WHEN TRUE THEN text 'xxx' ELSE array [1] END;
>
> "char" is no different other than, by default, it happens to look a
> lot like any value of text type.
So much so that it has the same name as a text type (wrapped in
quotes) and behaves a lot like one:
test=# SELECT CASE WHEN TRUE THEN text 'xxx' ELSE 'a'::"char" END;
case
------
xxx
(1 row)
test=# select upper('a'::"char");
upper
-------
A
(1 row)
test=# select char_length('a'::"char");
char_length
-------------
1
(1 row)
test=# select substring('a'::"char" from 1 for 1);
substring
-----------
a
(1 row)
Making it behave so much like character-based types and giving it a
name which implies that it is character based and storing a character
in it, but then not treating it like other character types in the
CASE context is bound to cause surprises for people.
> It's a different type (that happens to have some implicit casts to
> confuse things) and hence I can't see why invalid literals should
> not be thrown out.
Only, I guess, because of the name. If it weren't called "char" I
guess I wouldn't be concerned about people expecting it to behave
something like char. If "char" behaved more like char, the 'xxx'
literal wouldn't be taken as input to the type in the above CASE
statement.
-Kevin