Re: array_cat anycompatible change is breaking xversion upgrade tests

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org, Bruce Momjian <bruce@momjian.us>
Date: 2022-06-24T13:30:53Z
Lists: pgsql-hackers
On Fri, Jun 24, 2022 at 04:09:46PM +0500, Andrey Borodin wrote:
> Hi everyone!
> 
> Sorry for bumping old thread.

Please find this newer thread+patch here ;)
https://www.postgresql.org/message-id/20220614230949.GX29853@telsasoft.com

> On 25 May 2021, at 21:14, Justin Pryzby <pryzby@telsasoft.com> wrote:
> > 
> > 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.
> 
> We've just stumbled upon the problem in our service. Would it be backpatchable to add this check to pg_upgrade?

I guess you mean to backpatch to v14 for people upgrading from v13.

I realized that my latest patch would break upgrades from old servers, which do
not have array_position/s nor width_bucket, so ::reprocedure would fail.  Maybe
Andrey's way is better (checking proname rather than its OID).

-- 
Justin



Commits

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

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