Re: proposal: new polymorphic types - commontype and commontypearray

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> st 18. 3. 2020 v 17:14 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>> 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?

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

True, in actual production queries it's less likely that all the inputs
would be literal constants. So this is mainly about surprise factor,
or lack of it, for handwritten test queries.

> Maybe users can implement own fallback behave with next custom function

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

No, because if you've got that alongside foo2(anycompatible,
anycompatible) then your queries will fail due to both functions
matching anything that's promotable to text.

regards, tom lane