Re: array_cat anycompatible change is breaking xversion upgrade tests

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org, Bruce Momjian <bruce@momjian.us>
Date: 2021-05-25T16:14:58Z
Lists: pgsql-hackers
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.

(Re-defining the function before upgrading is possible when upgrading from v13,
only).

-- 
Justin



Commits

  1. doc: add PG 14 relnote item about array function references

  2. Work around cross-version-upgrade issues created by commit 9e38c2bb5.