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

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: BUG #5028: CASE returns ELSE value always when type is"char"
Дата
Msg-id 4A9E6AEB020000250002A8D1@gw.wicourts.gov
обсуждение исходный текст
Ответ на 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"  (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>)
Список 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 по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #5028: CASE returns ELSE value always when type is"char"