Re: proposal: new polymorphic types - commontype and commontypearray

st 18. 3. 2020 v 17:14 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> 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?
>

It is difficult question. What I know, this issue is less than we can
expect, because almost all functions are called with typed parameters
(columns, variables).

the fallback to text is enticement but maybe better is consistency with
other polymorphic types.

Maybe users can implement own fallback behave with next custom function

create function foo2(text, text) returns bool
language sql as 'select $1 = $2';

Regards

Pavel

> regards, tom lane
>