diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-04-29 15:24:37 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-04-29 15:24:37 -0400 |
commit | 404946d40109fb247f51b553ac00198765c6c1cb (patch) | |
tree | 23ae887e52cb7beefedafe83b8ad5400c03cd326 /src/backend/access/gist/gistvalidate.c | |
parent | 7cd542023056b1bb2d6b14313f49fd91db1dcca7 (diff) | |
download | postgresql-404946d40109fb247f51b553ac00198765c6c1cb.tar.gz postgresql-404946d40109fb247f51b553ac00198765c6c1cb.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/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions