st 18. 3. 2020 v 17:54 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
Pavel Stehule <pavel.stehule@gmail.com> writes: > st 18. 3. 2020 v 17:14 odesílatel Tom Lane <tgl@sss.pgh.pa.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.
It is working for anyelement
postgres=# create or replace function fx(anyelement, anyelement) postgres-# returns bool as $$ select $1=$2 $$ language sql; CREATE FUNCTION postgres=# create or replace function fx(text, text) returns bool as $$ select $1=$2 $$ language sql; CREATE FUNCTION postgres=# select fx(1,2); ┌────┐ │ fx │ ╞════╡ │ f │ └────┘ (1 row)
postgres=# select fx('ahoj','nazdar'); ┌────┐ │ fx │ ╞════╡ │ f │ └────┘ (1 row)