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

On Wed, Sep 02, 2009 at 03:50:05PM +0100, Greg Stark wrote:
> Perhaps we should stop thinking of "unknown" as, er, "unknown" and
> think of it as "text literal". A text literal has implicit casts to
> every data type but a normal text string has to be explicitly cast.

How does that help things? You seem to be keeping the semantics and
only changing the name, when it's the semantics that you seem to be
complaining about.

I'm pretty sure it's correct to treat it as "unknown", other
type-systems do this and it all works well. The thing that makes things
ambiguous is the ad-hoc polymorphism that exists in function calls
and operators. With PG's type system you know almost nothing about
any types involved in an arbitrary expression, operators are better
than functions (given the types of the arguments you know the return
type, with default parameters even this knowledge doesn't exist with
functions) but still leave things far too open to have any rigor without
spelling out types in full everywhere. 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. No need for "text 'hi'" in the second one
because || isn't defined for values of integer type.

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