Fix some more omissions in pg_upgrade's tests for non-upgradable types.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 29 Apr 2021 19:24:37 +0000 (15:24 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 29 Apr 2021 19:24:37 +0000 (15:24 -0400)
commit57c081de0afcd01bf47c46f015bf8886b01c2c21
tree5a4d8c3888224016b64641d5bfa4de30e5185859
parent94b9cb722552c37da78c8320bac1d5b55e34def6
Fix some more omissions in pg_upgrade's tests for non-upgradable types.

Commits 29aeda6e4 et al closed up some oversights involving not checking
for non-upgradable types within container types, such as arrays and
ranges.  However, I only looked at version.c, failing to notice that
there were substantially-equivalent tests in check.c.  (The division
of responsibility between those files is less than clear...)

In addition, because genbki.pl does not guarantee that auto-generated
rowtype OIDs will hold still across versions, we need to consider that
the composite type associated with a system catalog or view is
non-upgradable.  It seems unlikely that someone would have a user
column declared that way, but if they did, trying to read it in another
PG version would likely draw "no such pg_type OID" failures, thanks
to the type OID embedded in composite Datums.

To support the composite and reg*-type cases, extend the recursive
query that does the search to allow any base query that returns
a column of pg_type OIDs, rather than limiting it to exactly one
starting type.

As before, back-patch to all supported branches.

Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us
src/bin/pg_upgrade/check.c
src/bin/pg_upgrade/pg_upgrade.h
src/bin/pg_upgrade/version.c