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

From Greg Stark
Subject Re: BUG #5028: CASE returns ELSE value always when type is"char"
Date
Msg-id 407d949e0909020750q40c2b695h2cf53bc86baf2a1@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
List pgsql-bugs
On Wed, Sep 2, 2009 at 3:44 PM, Jeff Davis<pgsql@j-davis.com> wrote:
> On Wed, 2009-09-02 at 08:57 -0500, Kevin Grittner wrote:
>> > =A0 (a) leaving a literal as "unknown" until you've finished
>> > =A0 =A0 =A0 inferring types (current behavior)
>> > =A0 (b) casting every unknown to text immediately, and then trying to
>> > =A0 =A0 =A0 infer the types
>>
>> No, that's not it. =A0I'm wondering why it isn't treated as text.
>> Period. =A0Full stop. =A0Nothing to infer. =A0Anywhere that we have impl=
icit
>> casts defined from text to something else could, of course, still
>> operate; but it would be text. =A0No guessing.
>
> If you have very many implicit casts, I think you lose the
> predictability and safety you're looking for, and/or end up with a lot
> of errors that eliminate the convenience of implicit casting.

Perhaps we should stop thinking of "unknown" as, er, "unknown" and
think of it as "text literal". A text literal has implicit casts to
every data type but a normal text string has to be explicitly cast.

Hm, that's not quite right because things like array(1)||'5' don't
treat the '5' as a text literal. The "implicit cast" is preferred to
treating it as text.


--=20
greg
http://mit.edu/~gsstark/resume.pdf

pgsql-bugs by date:

Previous
From: Jeff Davis
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 typeis"char"