aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-04-29 15:24:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-04-29 15:24:37 -0400
commitd5722c92795d6300be731bd7af4b41567e402c79 (patch)
tree439cecb7279fa021f07335069dc0cabb50027f7e /src/backend/executor
parent56e234b6aff9c2e3b97fe647156012b5b175680f (diff)
downloadpostgresql-d5722c92795d6300be731bd7af4b41567e402c79.tar.gz
postgresql-d5722c92795d6300be731bd7af4b41567e402c79.zip
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
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions