Re: proposal: new polymorphic types - commontype and commontypearray

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)


>                         regards, tom lane
>