On Thu, Jul 29, 2021 at 05:01:24PM -0400, Tom Lane wrote: > Dave Cramer <davecra...@gmail.com> writes: > > So back to the original motivation for bringing this up. Recall that a > > cluster was upgraded. Everything appeared to work fine, except that the > > definitions of the functions were slightly different enough to cause a > > fatal issue on restoring a dump from pg_dump. > > Since pg_upgrade is now part of the core project, we need to make sure this > > is not possible or be much more insistent that the user needs to upgrade > > any extensions that require it. > > TBH, this seems like mostly the fault of the extension author. > The established design is that the SQL-level objects will be > carried forward verbatim by pg_upgrade. Therefore, any newer-version > shared library MUST be able to cope sanely with SQL objects from > some previous revision. The contrib modules provide multiple > examples of ways to do this. > > If particular extension authors don't care to go to that much > trouble, it's on their heads to document that their extensions > are unsafe to pg_upgrade.
I think we need to first give clear instructions on how to find out if an extension update is available, and then how to update it. I am thinking we should supply a query which reports all extensions that can be upgraded, at least for contrib. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
