Re: proposal: new polymorphic types - commontype and commontypearray

So ... there is a definitional question here that doesn't seem to have
been mentioned anywhere in the thread.  For the traditional polymorphic
types, we insist that at least one non-unknown input be supplied, thus
you get

regression=# create function foo(anyelement, anyelement) returns bool
regression-# language sql as 'select $1 = $2';
CREATE FUNCTION

regression=# select foo('a', 'b');
ERROR:  could not determine polymorphic type because input has type unknown

regression=# select foo('a', 'b'::text);
 foo
-----
 f
(1 row)

As this patch stands, the ANYCOMPATIBLE types also require that:

regression=# create function foo2(anycompatible, anycompatible) returns bool
language sql as 'select $1 = $2';
CREATE FUNCTION

regression=# select foo2('a', 'b');
ERROR:  could not determine polymorphic common type because input has type unknown

However, it seems to me that this is inconsistent with the definition,
namely that we resolve the common type the same way select_common_type()
does, because select_common_type() will choose TEXT when given all-unknown
inputs.  So shouldn't we choose TEXT here?

Admittedly, the fact that select_common_type() falls back to TEXT is a
bit of a wart, so maybe we don't want to propagate it here.  But if we
don't, we'll have to document the selection rule as almost but not
quite like what it says in section 10.5.  That seems confusing.

Documentation issues aside, I'm not quite sure whether this behavior
would be more or less preferable in practice than sticking with the
existing behavior.  It seems like it'd be convenient in some cases
but possibly allow mistakes to go undetected in others.

Thoughts?

                        regards, tom lane