Sam Mason <s...@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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs