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

From Jeff Davis
Subject Re: BUG #5028: CASE returns ELSE value always when type is "char"
Date
Msg-id 1251848886.31412.323.camel@monkey-cat.sm.truviso.com
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>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Jeff Davis
Date:
Subject: pg_ctl infinite loop and memory leak
Next
From: Tom Lane
Date:
Subject: Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.