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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
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 20:07:54
Message-ID: 28322.1251922074@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> 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.

There is already a weak preference for resolving unknown as text in
the presence of multiple alternatives. So I'm not sure that you're
suggesting anything different from what happens now. In particular,
weren't you the same person complaining a moment ago about
COALESCE(NULL,NULL) defaulting to text? Why is that bad if the
above is good?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sam Mason 2009-09-02 20:17:22 Re: BUG #5028: CASE returns ELSE value always when type is"char"
Previous Message Sam Mason 2009-09-02 20:04:26 Re: BUG #5028: CASE returns ELSE value always when type is"char"