On Thu, Jul 15, 2021 at 11:14 AM Jan Wieck <jan@wi3ck.info> 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.
Yep, and IIUC running "CREATE EXTENSION pg_stat_statements VERSION '1.5';" works correctly in v13 as does executing "ALTER EXTENSION pg_stat_statements UPDATE;" while version 1.5 is installed. So even without doing the copying of the old contrib libraries to the new server such a "one at a time" procedure would work just fine for this particular contrib extension.
And since the OP was unaware of the presence of the existing ALTER EXTENSION UPDATE command I'm not sure at what point a "lack of features" complaint here is due to lack of knowledge or actual problems (yes, I did forget too but at least this strengthens my position that one-at-a-time methods are workable, even today).
