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 4A9E841C020000250002A941@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>)
Список pgsql-bugs
Sam Mason <sam@samason.me.uk> wrote:

> I'd always thought '2001-01-01' was a valid date literal, seems the
> standard has required it to be prefixed by DATE at least back to
> SQL92.

Yep.  I don't know if it would be remotely feasible, but the
implementation which seems like it would be "standard-safe" but still
give reasonable concessions to those wanting to skip the extra
keystrokes of declaring the type of literals which are not character
based would be to go with the suggestion of having a character string
literal type, and change the semantics such that if there is a valid
interpretation of the statement with the character string literal
taken as text, it should be used; if not, resolve by current "unknown"
rules. Probably not feasible, but it seems likely it would make
everyone reasonably happy if it could be done.

That leaves the issue of NULL being forced to type text in the absence
of any type info in CASE, COALESCE, and NULLIF.  If there were a way
to say that these could return unknown type, that would be solved.
That doesn't seem as though it would be likely to be massively
difficult, although I could be wrong about that.

-Kevin

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: 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"