Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes) - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)
Date
Msg-id 20210608225618.GR16435@telsasoft.com
Whole thread Raw
In response to array_cat anycompatible change is breaking xversion upgrade tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)
List pgsql-hackers
@Bruce: Would you add something about this to the release notes before beta2?

I added it as an OpenItem.

On Tue, May 25, 2021 at 11:14:58AM -0500, Justin Pryzby wrote:
> On Thu, May 20, 2021 at 07:35:10PM -0400, Tom Lane wrote:
> > Justin Pryzby <pryzby@telsasoft.com> writes:
> > > On Wed, Nov 04, 2020 at 07:43:51PM -0500, Tom Lane wrote:
> > >> As was discussed in the thread leading up to that commit, modifying the
> > >> signature of array_cat and friends could break user-defined operators
> > >> and aggregates based on those functions.  It seems to me that the
> > >> usability gain from this change is worth that cost, but it is causing
> > >> an issue for xversion tests.
> > 
> > > But I think this should be called out as an incompatible change in the release
> > > notes.
> > 
> > If it was not, yes it should be.
> 
> @Bruce, I propose:
> 
> Some system functions are changed to accept "anycompatiblearray" arguments.
> This causes failures when restoring a database backup or running pg_restore if
> there were aggregate functions defined using those functions with their
> original argument types.
> 
> Such aggregate functions should be dropped before upgrade/restore and then
> re-created afterwards using the "anycompatible" functions.  The affected
> functions are: array_append, array_prepend, array_cat, array_position,
> array_positions, array_remove, array_replace, and width_bucket.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: logical replication of truncate command with trigger causes Assert
Next
From: Mark Dilger
Date:
Subject: Re: logical replication of truncate command with trigger causes Assert