samrose left a comment

Add test to verify that all extension versions from PostgreSQL 15 can successfully upgrade to PostgreSQL 17 using pg_upgrade.The test now validates:- Each PG 15 extension version can be upgraded to PG 17- Extension update scripts are properly generated during upgrade- Version handling works correctly with and without update scripts- Final extension versions match expected values after upgrade

…ade compatibilityWhen upgrading PostgreSQL versions, pg_upgrade needs access to old extensionversions sql to migrate from. This adds unsupported pg_graphql versions (those notcompilable with current PostgreSQL) as SQL-only packages, ensuring migrationpaths exist when upgrading from older PostgreSQL versions.

…pgrade compatibilityWhen upgrading PostgreSQL versions, pg_upgrade needs access to old extensionversions sql to migrate from. This adds unsupported pg_graphql versions (those notcompilable with current PostgreSQL) as SQL-only packages, ensuring migrationpaths exist when upgrading from older PostgreSQL versions.

When upgrading from PostgreSQL 15 to 17, pg_stat_monitor version 1.0(PG 15-only) cannot be migrated as it uses .sql.in template files thatreference MODULE_PATHNAME without proper processing for the target version.This marks version 1.0 as not pg_upgrade compatible and filters it fromthe version test list, allowing the test to use version 2.1 (which supportsboth PG 15 and 17) for pg_upgrade validation instead. Version 1.0 remainsavailable for PG 15 installations.Version 2.1 has different schemas on PostgreSQL 15 vs 17 despite sharingthe same version number. On PG 15 it uses the older schema with blk_read_timeand blk_write_time columns, while on PG 17 it uses a newer schema withshared_blk_read_time, shared_blk_write_time, local_blk_read_time,local_blk_write_time and additional JIT statistics columns. During pg_upgradefrom PG 15 to 17, the extension version remains 2.1 without schema migrationsince no update script is generated. Fresh installations on PG 17 receivethe new schema while pg_upgrade retains the old schema, creating a testconflict as both scenarios share the same expected output file.A custom test implementation skips pg_regress validation after pg_upgradewhen no update script is generated, since the schema mismatch is expectedbehavior. This maintains full test coverage for fresh installations throughthe regular psql_17 check while validating extension version compatibilityfor pg_upgrade scenarios.