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

Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
 
>> No, that's not it.  I'm wondering why it isn't treated as text. 
>> Period.  Full stop.  Nothing to infer.
> 
> Because then we would have to provide implicit casts from text to
> everything else, which would be horribly dangerous.
 
I would like that even less.  I like errors on type conflicts.
 
>> In my view, it is wrong that any of those work.  I would expect to
>> have to code one of these:
>  
>> select now() < date '2009-01-01';  -- implicit casts should cover
>> select now() < timestamp with time zone '2009-01-01 00:00:00.0';
> 
> The current design is a compromise between usability and strictness
> of semantics.  This proposal appears to be all strictness and no
> usability.
 
I was not proposing anything; I was trying to understand the reasons
for the current behavior so that I could think about what might make
sense to address some of the places where current behavior causes a
result which is different from a non-error result should be obtained
under the standard.  I couldn't begin to anticipate what might be
acceptable in these situations without understanding the reason things
are as they are.
 
I do understand that there will be "convenience" extensions to the
standard -- all products do that.  I wasn't sure whether that was the
reason for the behavior or whether there was something else in play.
 
Thanks for clarifying,
 
-Kevin