Add table to regression tests for binary-compatibility checks in pg_upgrade
authorMichael Paquier <michael@paquier.xyz>
Thu, 18 Nov 2021 01:37:15 +0000 (10:37 +0900)
committerMichael Paquier <michael@paquier.xyz>
Thu, 18 Nov 2021 01:37:15 +0000 (10:37 +0900)
commit835bcba8b8d72a00cecc5431b67e70bbea93f947
tree035103527eddd125d31b1e041dca1a314841339b
parent5f1148224bd78bcf3bf7d916b8fe85dd820c52c6
Add table to regression tests for binary-compatibility checks in pg_upgrade

This commit adds to the main regression test suite a table with all
the in-core data types (some exceptions apply).  This table is not
dropped, so as pg_upgrade would be able to check the binary
compatibility of the types tracked in the table.  If a new type is added
in core, this part of the tests would need a refresh but the tests are
designed to fail if that were to happen.

As this is useful for upgrades and that these rely on the objects
created in the regression test suite of the old version upgraded from,
a backpatch down to 12 is done, which is the last point where a binary
incompatible change has been done (7c15cef).  This will hopefully be
enough to find out if something gets broken during the development of a
new version of Postgres, so as it is possible to take actions in
pg_upgrade itself in this case (like 0ccfc28 for sql_identifier).

An area that is not covered yet is related to external modules, which
may create their own types.  The testing infrastructure of pg_upgrade is
not integrated yet with the external modules stored in core
(src/test/modules/ or contrib/, all use the same database name for their
tests so there would be an overlap).  This could be improved in the
future.

Author: Justin Pryzby
Reviewed-by: Jacob Champion, Peter Eisentraut, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/20201206180248.GI24052@telsasoft.com
Backpatch-through: 12
src/test/regress/expected/sanity_check.out
src/test/regress/expected/type_sanity.out
src/test/regress/sql/type_sanity.sql