Re: proposal: new polymorphic types - commontype and commontypearray - Mailing list pgsql-hackers

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

* 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'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

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

Is it possible somehow to invoke any of these functions?

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.