Re: BUG #5028: CASE returns ELSE value always when type is"char"

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> In a formal sense the type information available is the same, ie,
> none.

Well, in the sense that an international standard is formal, there is
a formal difference, in that one has no type information and the other
is a character string.  However:

> The argument that SQL says 'foo' must be character, so we should
> too, is greatly weakened by the fact that SQL has such an
> impoverished set of built-in types.  If we want to treat
> user-defined types as anything approaching first-class types, we
> have to be pretty suspicious of that restriction.

Another big clue for me in terms of the community perspective on this.
Thanks.

I think that the current approach leaves a small number of corner
cases where we break SQL compliance.  I think it's worthwhile trying
to fix that.  Whether that's best done by identifying the individual
corners and fixing them independently as aberrations, or implementing
some changes which provide the PostgreSQL extensions in a way that
doesn't tend to break standard usage (and of course has little or no
impact on current PostgreSQL users), is beyond my ken.

I'm also not suggesting that this is the most urgent issue around.
If anyone can suggest an appropriate wording for a TODO on the topic,
I'll happily shut up and move on....  ;-)

-Kevin