From: Tom Lane <tgl@sss.pgh.pa.us>
To: Pavel Stehule <pavel.stehule@gmail.com>
cc: =?UTF-8?B?RGF2aWQgVHVyb8WI?= <Turon.David@seznam.cz>,
        edouard.hibon@free.fr,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>,
        "David G. Johnston" <david.g.johnston@gmail.com>
Subject: Re: BUG #17206: the function array_cat(anyarray,
 anyarray) does not exist
In-reply-to: 
 <CAFj8pRCnxTiCBUCM1OsBdpUq1YsioeHb2EMyHRp8c9rYbKE+zA@mail.gmail.com>
References: 
 <CAKFQuwbKPYOuaexih1fMDPKa7kTjLSVjNdWCRHn7iJ2+oukpHg@mail.gmail.com>
 <17206-f0a6b77a0a7b8499@postgresql.org> <3266664.1633045937@sss.pgh.pa.us>
 <13T.5{S3.6C2WnHnPYu}.1YzDSc@scif.cz>
 <CAFj8pRCnxTiCBUCM1OsBdpUq1YsioeHb2EMyHRp8c9rYbKE+zA@mail.gmail.com>
Comments: In-reply-to Pavel Stehule <pavel.stehule@gmail.com>
	message dated "Thu, 11 Aug 2022 13:08:01 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <482920.1660226013.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Thu, 11 Aug 2022 09:53:33 -0400
Message-ID: <482921.1660226013@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/482921.1660226013%40sss.pgh.pa.us>
Precedence: bulk

Pavel Stehule <pavel.stehule@gmail.com> writes:
> čt 11. 8. 2022 v 12:17 odesílatel David Turoň <Turon.David@seznam.cz>
> napsal:
>> Is bug that function with anycompatiblearray didn't accept anyarray data
>> type?

> and yes - anyarray type is distinct from anycompatiblearray
> so you can write
> create or replace function fx(anyarray, anyarray, anycompatiblearray,
> anycompatiblearray) that means

Yeah.  We could introduce a cast from anyarray to anycompatiblearray,
but I fear it'd play hob with the ability to use both polymorphic
families in one function signature.

More to the point, though, the casts are required here in any case.
Pre-v14, you got a different error, but it was still an error.
Neither in principle nor in practice would it be safe to pass
pg_stats.most_common_vals to array_position() without any cast.
array_position expects the array's element type to match the type
of its second argument, and will probably crash if it doesn't.
So forcing most_common_vals to flat text and then to text[] is
essential to unify the incompatible types found in pg_stat.

			regards, tom lane