Re: BUG #5028: CASE returns ELSE value always when type is"char" - Mailing list pgsql-bugs

From Kevin Grittner
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 4A9E6AEB020000250002A8D1@gw.wicourts.gov
Whole thread Raw
In response to Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
Responses Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
List pgsql-bugs
Sam Mason <sam@samason.me.uk> wrote:

> If we did follow Kevin's request directly, should we also be
> specifying the type of NULL?

I don't *think* the SQL standard requires that, and barring that I
don't see any compelling reason to type NULL.  One problem I do see
with the current scheme, however, is that NULL *does* get typed to
text when it makes no sense.  In my view, a CASE expression which has
only NULL for its return values, or an abbreviated form of CASE, such
as COALESCE or NULLIF, should be evaluated exactly the same as if they
were replaced by NULL itself.  For example, COALESCE(NULL, NULL)
currently yields NULL::text.  In my view that's wrong.  I view it as a
bug, but that seems to be a hard sell here.

Likewise, I think that in the query which started this thread, the
cast to "char" is not sensible.  I'm not sure how that could be
resolved, but it doesn't seem correct to me.

-Kevin

pgsql-bugs by date:

Previous
From: Sam Mason
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Next
From: Tom Lane
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"