Subject: Re: pgsql: Declare assorted array functions using anycompatible not
 anyelem
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@lists.postgresql.org
References: <E1kaQ2c-0005lx-Eg@gemulon.postgresql.org>
 <fff35eb5-765c-3e60-3a2a-45ba5f88777d@dunslane.net>
 <1999748.1604957386@sss.pgh.pa.us>
From: Andrew Dunstan <andrew@dunslane.net>
Message-ID: <b300679b-6410-9124-271c-73893a2c3a1f@dunslane.net>
Date: Mon, 9 Nov 2020 17:00:05 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.3.1
MIME-Version: 1.0
In-Reply-To: <1999748.1604957386@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


On 11/9/20 4:29 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 11/4/20 4:10 PM, Tom Lane wrote:
>>> Declare assorted array functions using anycompatible not anyelement.
>> This patch broke cross-version pg_upgrade testing.
> Uh, yeah ... didn't you get my two prior messages about that?


Yes, I did, although by the time you sent them out I'd already modified
crake.


>
>> I have cured crake
>> for the moment by having it execute this in the source database:
> I think probably the right fix is just to change that test case to
> use a different implementation function, per [1].  I'm holding off
> pushing the fix till after this week's wraps, though.


I'd be ok with that. Can we devise a fix that will work all the way back
to 9.2, which is where we start upgrade testing?


>
>> But I wonder if we really want to make it impossible to upgrade
>> databases with aggregates that contain these functions?
> If I thought that user-defined aggregates relying on array_cat were
> really a thing (and not just a test case), I'd be more concerned about
> this.  But it's hard to see why users shouldn't use array_agg() instead
> of rolling their own.
>
> 	


Possibly something that's been migrated from before we had array_agg.


cheers


andrew