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)  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: logical replication of truncate command with trigger causes Assert
Следующее
От: Peter Smith
Дата:
Сообщение: Re: row filtering for logical replication