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

On Tue, 2009-09-01 at 13:49 -0500, Kevin Grittner wrote:
> I figured that; I'm just trying to understand what seems to me like an
> odd wart on the type system. I figure I must be missing something
> important, so I'd kinda like to find out what that is.

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

In general, option (b) eliminates information that might be useful for
making good inferences about the correct operators to use, and also
finding cases of ambiguity.

For instance, consider the current behavior:

1. select now()::text < 'January 01, 2009'; -- true
2. select now() < 'January 01, 2009'; -- false
3. select now() < 'January 01, 2009'::text;
ERROR: operator does not exist: timestamp with time zone < text

Example #2 shows that we can infer the the RHS is of type timestamptz
based on the type of the LHS. That's desirable behavior in any
type-inferencing system -- without it you might as well just explicitly
cast all literals. Example #3 is ambiguous: we have no way to know
whether to choose "< (timestamptz, timestamptz)" or "< (text, text)",
and an ERROR is desirable behavior to avoid confusing results.

But you can't have both of those desirable behaviors unless you are
somehow aware that "'January 01, 2009'" is something more malleable than
"now()" in example #2. Calling the RHS "unknown" in example #2 gives us
that information.

Regards,
Jeff Davis