Re: BUG #17387: Working in PG13 but not in PGH14: array_agg(RECORD)

Pavel Stehule <pavel.stehule@gmail.com> writes:
> pá 28. 1. 2022 v 21:19 odesílatel Pavel Stehule <pavel.stehule@gmail.com>
> napsal:
>> Probably it is side effect of this patch
>>
https://github.com/postgres/postgres/commit/9e38c2bb5093ceb0c04d6315ccd8975bd17add66#diff-e2a931f90073b784e341960c6fe1f48aaea4b5d57eb4388143534eec3863477b

> anycompatible* types are less sensitive to different data types, but it
> increases a risk of possibility of errors when more than one function can
> be detected for execution on analysis of function's signatures.

Hmm.  We have

regression=# \do ||
                                                   List of operators
   Schema   | Name |   Left arg type    |   Right arg type   |    Result type     |             Description


------------+------+--------------------+--------------------+--------------------+-------------------------------------
 pg_catalog | ||   | anycompatible      | anycompatiblearray | anycompatiblearray | prepend element onto front of array
 pg_catalog | ||   | anycompatiblearray | anycompatible      | anycompatiblearray | append element onto end of array
 pg_catalog | ||   | anycompatiblearray | anycompatiblearray | anycompatiblearray | concatenate
 ...

where before it was

 pg_catalog | ||   | anyelement    | anyarray       | anyarray    | prepend element onto front of array
 pg_catalog | ||   | anyarray      | anyelement     | anyarray    | append element onto end of array
 pg_catalog | ||   | anyarray      | anyarray       | anyarray    | concatenate

which was non-ambiguous because in this usage, anyelement
wouldn't match an array type.  I wonder why that's not
happening with the anycompatible family?

We could s/anycompatible/anycompatiblenonarray/ in the
catalog entries, but it seems like we shouldn't have to.

            regards, tom lane