st 18. 3. 2020 v 17:54 odesílatel Tom Lane <t...@sss.pgh.pa.us> napsal:
> Pavel Stehule <pavel.steh...@gmail.com> writes:
> > st 18. 3. 2020 v 17:14 odesílatel Tom Lane <t...@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)
> regards, tom lane
>
