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 10764.1251911947@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5028: CASE returns ELSE value always when type is"char"  (Sam Mason <sam@samason.me.uk>)
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"  (Sam Mason <sam@samason.me.uk>)
List pgsql-bugs
Sam Mason <sam@samason.me.uk> writes:
> ... For example:

>   CREATE FUNCTION add(int,int) RETURNS int LANGUAGE sql
>      AS $$ SELECT $1 + $2; $$;

>   CREATE FUNCTION add(int,int,int DEFAULT NULL) RETURNS text LANGUAGE sql
>     AS $$ SELECT ($1 + $2)::text; $$;

> What type should it attribute to the result of:

>   SELECT add(1,2);

> In fact it doesn't seem to want to play ball at all.  Even given the
> apparently unambiguous:

>   SELECT 1+add(1,2);
> or
>   SELECT 'hi'||add(1,2);

> It doesn't get anywhere.

Well, no, because our type resolution is bottom-up; it does not consider
context when trying to resolve the overloaded "add()" function
reference.  "Unknown" is the only part of the system that allows for any
delay at all in identifying the type of a construct, and even that is
limited to a literal and its first-level surrounding context.

It's interesting that you want to go in 100% the opposite direction from
Kevin, who seems to want to eliminate type inference altogether.  Maybe
our current compromise isn't too bad, if it makes everybody unhappy in
opposite directions ;-)

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5025: Aggregate function with subquery in 8.3 and 8.4.
Next
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5028: CASE returns ELSE value always when type is"char"