On Thu, Jul 15, 2021 at 9:58 AM Jan Wieck <j...@wi3ck.info> wrote: > On 7/15/21 12:46 PM, David G. Johnston wrote: > > > I am an application developer who operates on the principle of "change > > only one thing at a time". > > Which pg_upgrade by definition isn't. It is bringing ALL the changes > from one major version to the target version, which may be multiple at > once. Including, but not limited to, catalog schema changes, SQL > language changes, extension behavior changes and utility command > behavior changes. > > On that principle, you should advocate against using pg_upgrade in the > first place. > > Not that I use extensions a whole lot (yes, my overall experience here is slim) but I would definitely prefer those that allow me to stay on a single PostgreSQL major version while migrating between major versions of their own product. Extensions that don't fit this model (i.e., choose to treat their major version as being the same as the major version of PostgreSQL they were developed for) must by necessity be upgraded simultaneously with the PostgreSQL server. 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..."
David J.
