Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)
От | Bruce Momjian |
---|---|
Тема | Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes) |
Дата | |
Msg-id | 20210609000246.GB26035@momjian.us обсуждение исходный текст |
Ответ на | Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes) (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)
|
Список | pgsql-hackers |
On Tue, Jun 8, 2021 at 05:56:18PM -0500, Justin Pryzby wrote: > @Bruce: Would you add something about this to the release notes before beta2? > > I added it as an OpenItem. OK, see below. > 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. Uh, this is _using_ these functions in aggregates, or changing the system functions' argument types, right? I didn't think we supported dump/restore of modified system tables. > > > > > > > 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. I read the entire thread and I see: pg_restore: error: could not execute query: ERROR: function array_append(anyarray, anyelement) does not exist Command was: CREATE AGGREGATE public.array_accum(anyelement) ( SFUNC = array_append, STYPE = anyarray, INITCOND = '{}', PARALLEL = safe ); This involves creating an aggreate that _uses_ these array functions as their state transition function? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
В списке pgsql-hackers по дате отправления: