Re: pg_upgrade does not upgrade pg_stat_statements properly - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade does not upgrade pg_stat_statements properly
Date
Msg-id 20210715182624.GB14027@momjian.us
Whole thread Raw
In response to Re: pg_upgrade does not upgrade pg_stat_statements properly  (Jan Wieck <jan@wi3ck.info>)
List pgsql-hackers
On Thu, Jul 15, 2021 at 02:14:28PM -0400, Jan Wieck wrote:
> On 7/15/21 1:10 PM, David G. Johnston wrote:
> > ... But while PostgreSQL doesn't really have a choice here - it cannot
> > be expected to subdivide itself - extensions (at least external ones -
> > PostGIS is one I have in mind presently) - can and often do attempt to
> > support multiple versions of PostgreSQL for whatever major versions of
> > their product they are offering.  For these it is possible to adhere to
> > the "change one thing at a time principle" and to treat the extensions
> > as not being part of "ALL the changes from one major version to the
> > target version..."
> 
> You may make that exception for an external extension like PostGIS. But I
> don't think it is valid for one distributed in sync with the core system in
> the contrib package, like pg_stat_statements. Which happens to be the one
> named in the subject line of this entire discussion.

Yes, I think one big issue is that the documentation of the new server
might not match the API of the extension installed on the old server.

There has been a lot of discussion from years ago about why we can't
auto-upgrade extensions, so it might be good to revisit that.

-- 
  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 by date:

Previous
From: Jan Wieck
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: "David G. Johnston"
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly