Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcTxU-000350-LD for pgsql-committers@arkaria.postgresql.org; Tue, 10 Nov 2020 13:45:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kcTxT-0007Ns-GC for pgsql-committers@arkaria.postgresql.org; Tue, 10 Nov 2020 13:45:15 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcTxT-0007Nl-Ad for pgsql-committers@lists.postgresql.org; Tue, 10 Nov 2020 13:45:15 +0000 Received: from relay2-d.mail.gandi.net ([217.70.183.194]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kcTxQ-0008If-NM for pgsql-committers@lists.postgresql.org; Tue, 10 Nov 2020 13:45:14 +0000 X-Originating-IP: 99.10.92.30 Received: from [192.168.10.146] (99-10-92-30.lightspeed.rlghnc.sbcglobal.net [99.10.92.30]) (Authenticated sender: adsend@dunslane.net) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 6BBD940015; Tue, 10 Nov 2020 13:45:07 +0000 (UTC) Subject: Re: pgsql: Declare assorted array functions using anycompatible not anyelem To: Tom Lane Cc: pgsql-committers@lists.postgresql.org References: <1999748.1604957386@sss.pgh.pa.us> <2001798.1604960149@sss.pgh.pa.us> <52030649-c25c-c4e6-8316-2fd4f9a24f8b@dunslane.net> <2008195.1604961694@sss.pgh.pa.us> From: Andrew Dunstan Message-ID: Date: Tue, 10 Nov 2020 08:45:06 -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: <2008195.1604961694@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 11/9/20 5:41 PM, Tom Lane wrote: > > What I have in mind to apply to 9.5 through 13 is per attached. > You could either redefine the aggregate similarly in 9.2-9.4, > or just drop it. I doubt the latter leads to any interesting > loss of coverage for xversion upgrade, as there's plenty of other > user-defined aggregates in the regression database. You also need to modify first_el_agg_any. Here's what I have working on crake::         if ($oversion le 'REL9_4_STABLE')         {             # this is to be fixed in 9.5 and later             $prstmt = join(';',                            'drop aggregate if exists public.array_cat_accum(anyarray)',                            'CREATE AGGREGATE array_larger_accum (anyarray) ' .                            ' ( ' .                            '   sfunc = array_larger, ' .                            '   stype = anyarray, ' .                            '   initcond = $${}$$ ' .                            '  ) ' );             system( "$other_branch/inst/bin/psql -X -e "                       . " -c '" . $prstmt . "' "                       . "regression "                       . ">> '$upgrade_loc/$oversion-copy.log' 2>&1");             return if $?;         }         # drop this branch when upstream is renovated         else         {             $prstmt = join(';',                           'drop aggregate if exists public.array_cat_accum(anyarray)',                           'drop aggregate if exists public.first_el_agg_any(anyelement)');             system( "$other_branch/inst/bin/psql -X -e "                       . " -c '$prstmt' "                       . "regression "                       . ">> '$upgrade_loc/$oversion-copy.log' 2>&1");             return if $?;         } When you fix the live branches I'll delete the "else" branch and push the change to the git repo. cheers andrew