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 4A9E841C020000250002A941@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>)
List 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 by date:

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