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 28322.1251922074@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>)
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:
> 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

pgsql-bugs by date:

Previous
From: Sam Mason
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"
Next
From: Sam Mason
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"