Re: BUG #5028: CASE returns ELSE value always when type is"char" - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 2350.1251900670@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5028: CASE returns ELSE value always when type is"char"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: BUG #5028: CASE returns ELSE value always when type is"char"  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Jeff Davis <pgsql@j-davis.com> wrote:
>> If I understand your question, you're comparing:
>>
>> (a) leaving a literal as "unknown" until you've finished
>> inferring types (current behavior)
>> (b) casting every unknown to text immediately, and then trying to
>> infer the types

> 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.

> 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';

[ shrug... ]  The current design is a compromise between usability
and strictness of semantics.  This proposal appears to be all strictness
and no usability.  No thanks ... even without any backward-compatibility
considerations, I wouldn't find this to be an improvement.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
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"