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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <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 18:55:28
Message-ID: 4A9E7950020000250002A92C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> And I'm not even sure how I'd explain the rules to someone.
>
> text is preferred to "char" which is preferred to unknown.
>
> This particular example would be less confusing if 'Hey'::"char"
> threw an error, but that behavior is the result of an ancient
> (bad?) decision in the input function of one legacy datatype.
> It's not, IMNSHO, evidence of an overall failure of the type system
> as a whole.

So the behavior of the "char" type is anomalous in this regard? Other
character-based types behave like varchar (which has the behavior I
would expect here)? That is encouraging. Why isn't the behavior of
"char" in this regard considered a bug to be fixed?

I'm not sure I'm exactly understanding why the varchar(2) worked,
though. Perhaps it would be more clear if I grasped why *that* one
does what I would think is the right thing. At this point my first
guess would be that it discards the length for a varchar, and just
treats it as text (or some other "neutral" character-based type). If
so, perhaps "char" should do the same?

-Kevin

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sam Mason 2009-09-02 19:07:48 Re: BUG #5028: CASE returns ELSE value always when type is"char"
Previous Message Tom Lane 2009-09-02 18:49:55 Re: BUG #5028: CASE returns ELSE value always when type is"char"