Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Date: 2021-06-12T01:42:41Z
Lists: pgsql-hackers
On Fri, Jun 11, 2021 at 08:19:48PM -0500, Justin Pryzby wrote: > On Fri, Jun 11, 2021 at 09:12:55PM -0400, Bruce Momjian wrote: > > OK, I used some of your ideas and tried for something more general; > > patch attached. > > This is good. > > But I wonder if "dropped before upgrading" is too specific to pg_upgrade? > > Dropping the aggregate before starting a backup to be restored into a new > version seems like a bad way to do it. More likely, I would restore whatever > backup I had, get errors, and then eventually recreate the aggregates. I am actually unclear on that. Do people really restore a dump and just ignore errors, or somehow track them and go back and try to fix them. Isn't there a cascading effect if other things depend on it? How do they get the object definitions from a huge dump file? What process should we recommend? I have just never seen good documentation on how this handled. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
Commits
-
doc: add PG 14 relnote item about array function references
- 25dfb5a831a1 14.0 landed
-
Work around cross-version-upgrade issues created by commit 9e38c2bb5.
- d3d4f7233a3e 11.11 landed
- cea97d98f167 9.6.21 landed
- 97f73a978fc1 14.0 landed
- 6c91e28224f6 9.5.25 landed
- 5ce51f8280d3 12.6 landed
- 5c456d308071 13.2 landed
- 253f02c46f0e 10.16 landed