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

On Wed, Sep 02, 2009 at 01:19:07PM -0400, Tom Lane wrote:
> Sam Mason <sam(at)samason(dot)me(dot)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.

OK, I got distracted and my example was bad.

> 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 ;-)

The current compromise has worked for a while so there's no immediate
reason to change it. I wasn't interpreting Kevin's request directly
as I don't think he really means what he's saying and really wants
an unambiguous way of writing literals in queries. I think it's
easier to get this without specifying types everywhere and introducing
constraints elsewhere to maintain what compatibility we've got with the
SQL standard.

If we did follow Kevin's request directly, should we also be specifying
the type of NULL?

--
Sam http://samason.me.uk/