Re: proposal: new polymorphic types - commontype and commontypearray

po 25. 11. 2019 v 14:35 odesílatel Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
napsal:

> > On Mon, Jun 17, 2019 at 05:31:40AM +0200, Pavel Stehule wrote:
> >
> > > I like anycompatible and anycompatiblearray.
> > >
> > > I'll update the patch
> > >
> >
> > and here it is
>
> Thanks for the patch! I've reviewed it a bit, and have a few small
> commentaries:
>
> * There are few traces of copy paste in comments
>
> +static Oid
> +select_common_type_from_vector(int nargs, Oid *typeids, bool noerror)
> ...
> + /*
> + * Nope, so set up for the full algorithm. Note that at this
> point, lc
> + * points to the first list item with type different from pexpr's;
> we need
> + * not re-examine any items the previous loop advanced over.
> + */
>

> Seems like it was taken from select_common_type, but in
> select_common_type_from_vector there is no `lc`, since it doesn't
> accept a list.
>

fixed

>
> * I guess it's would be beneficial to update also commentaries for
> check_generic_type_consistency and enforce_generic_type_consistency
>
> * The argument consistency rules are:
> *
> * 1) All arguments declared ANYELEMENT must have the same datatype.
> * ...
>
> Since they do not reflect the current state of things in this patch.
>

I add rules 8 and 9 about ANYCOMPATIBLE types

> * I've noticed that there is a small difference in how anyelement and
> anycompatible behave, namely anycompatible do not handle unknowns:
>
> =# select 'aaa'::anyelement;
> anyelement
> ------------
> aaa
>
> =# select 'aaa'::anycompatible;
> ERROR: 42846: cannot cast type unknown to anycompatible
> LINE 1: select 'aaa'::anycompatible;
> ^
> LOCATION: transformTypeCast, parse_expr.c:2823
>
>
It happens due to unknowns being filtered out quite early in
> check_generic_type_consistency and similar. By itself this difference it
> not a
> problem, but it causes different error messages in functions:
>
> -- this function accepts anycompatible
> =# select test_anycompatible('aaa');
> ERROR: 42883: function test_anycompatible(unknown) does not exist
> LINE 1: select test_anycompatible('aaa');
> ^
> HINT: No function matches the given name and argument types. You
> might need to add explicit type casts.
> LOCATION: ParseFuncOrColumn, parse_func.c:627
>
> -- this function accepts anyelement
> =# select test_anyelement('aaa');
> ERROR: 42804: could not determine polymorphic type because input
> has type unknown
> LOCATION: enforce_generic_type_consistency, parse_coerce.c:2177
>

fixed

> Although of course it's not that serious.
>
> * I'm also curious about the following situation:
>
> =# create function test_both(a anycompatible) returns
> anycompatible as $$
> begin
> return a;
> end$$ language plpgsql;
> CREATE FUNCTION
>
> =# create function test_both(a anyelement) returns anyelement as $$
> begin
> return a;
> end$$ language plpgsql;
> CREATE FUNCTION
>
> =# select test_both('aaa'::text);
> ERROR: 42725: function test_both(text) is not unique
> LINE 1: select test_both('aaa'::text);
> ^
> HINT: Could not choose a best candidate function. You might need
> to add explicit type casts.
> LOCATION: ParseFuncOrColumn, parse_func.c:568
>
> =# select test_both('aaa'::anyelement);
> ERROR: 42804: could not determine polymorphic type because input
> has type unknown
> LOCATION: enforce_generic_type_consistency, parse_coerce.c:2177
>

fixed

> Is it possible somehow to invoke any of these functions?
>

unfortunately - it's not possible - the construct 'aaa'::"polymorphic type"
doesn't create a value of this type - result type is a text type, and then
it doesn't help in this situation.

It is similar if you create fx(anyelement) and fx(anyarray) - and you
cannot to call fx(anyelement) by fx(1::anyelement)

> Other than that the functionality looks pretty solid. It may look obvious,
> but
> I've also tested performance in different use cases for anycompatible,
> looks
> the same as for anyelement.
>

Thank you for review, I am sending fixed patch

Regards

Pavel