COALESCE and NULLIF semantics

Given the desire to defer pinning the type of a literal, for better
support of user defined types, I think the current semantics of all
the conditional expressions:

http://www.postgresql.org/docs/8.4/interactive/functions-conditional.html

are somewhat broken.

As a quick sample of something which I believe implements the correct
semantics for COALESCE and NULLIF, see the functions below. I'm not
suggesting that it would be best to treat these as functions, just
showing what I think the correct semantics would be. I also think
that the ease of definition shows that such an interpretation would
not necessarily be fairly characterized as a huge wart on the type
system.

create function "coalesce"(v1 unknown, v2 unknown)
returns unknown language plpgsql as
'begin if v1 is not null then return v1; end if; return v2; end;';

create function "coalesce"(v1 anyelement, v2 anyelement)
returns anyelement language plpgsql as
'begin if v1 is not null then return v1; end if; return v2; end;';

create function "nullif"(v1 unknown, v2 unknown)
returns unknown language plpgsql as
'begin if v1 = v2 then return null; end if; return v1; end;';

create function "nullif"(v1 anyelement, v2 anyelement)
returns anyelement language plpgsql as
'begin if v1 = v2 then return null; end if; return v1; end;';

select "coalesce"(null, null), pg_typeof(("coalesce"(null, null)));
coalesce | pg_typeof
----------+-----------
| unknown
(1 row)

select "coalesce"(null, '1'), pg_typeof(("coalesce"(null, '1')));
coalesce | pg_typeof
----------+-----------
1 | unknown
(1 row)

select "coalesce"('1', '2'), pg_typeof(("coalesce"('1', '2')));
coalesce | pg_typeof
----------+-----------
1 | unknown
(1 row)

select "coalesce"(null, '1'::text), pg_typeof(("coalesce"(null,
'1'::text)));
coalesce | pg_typeof
----------+-----------
1 | text
(1 row)

select "coalesce"(null, 1), pg_typeof(("coalesce"(null, 1)));
coalesce | pg_typeof
----------+-----------
1 | integer
(1 row)

The CASE predicate would also need to behave in this manner. Probably
GREATEST and LEAST, as well.

-Kevin