Yep, and IIUC running "CREATE EXTENSION pg_stat_statements VERSION '1.5';" works correctly in v13 as does executing
While it does work there are issues with dumping and restoring a database with the old version of pg_stat_statements in it that would only be found by dumping and restoring.
I'm unsure how this impacts the broader discussion. At worse you'd have a chance to manually run the update command on the new cluster before using dump/restore.
"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.
You cannot copy the old contrib libraries into the new server. This will fail due to changes in the API and various exported variables either not being there or being renamed.
If this is true then the docs have a bug. It sounds more like the documentation should say "ensure that the new cluster has extension libraries installed that are compatible with the version of the extension installed on the old cluster". Whether we want to be even more specific with regards to contrib I cannot say - it seems like newer versions largely retain backward compatibility so this is basically a non-issue for contrib (though maybe individual extensions have their own requirements?)
but it fails to say that the versions that are installed may need to be updated.
OK, especially as this seems useful outside of pg_upgrade, and if done separately is something pg_upgrade could just run as part of its new cluster evaluation scripts. Knowing whether an extension is outdated doesn't require the old cluster.
