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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <pgsql-bugs(at)postgresql(dot)org>,"Sam Mason" <sam(at)samason(dot)me(dot)uk>
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date: 2009-09-02 19:41:32
Message-ID: 4A9E841C020000250002A941@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Sam Mason <sam(at)samason(dot)me(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2009-09-02 19:59:54 Re: BUG #5028: CASE returns ELSE value always when type is"char"
Previous Message Sam Mason 2009-09-02 19:34:51 Re: BUG #5028: CASE returns ELSE value always when type is"char"