pgTap has a view that references pg_proc; to support introspection of functions and aggregates. That view references
proisaggin versions < 11, and prokind in 11+. pgtap's make process understands how to handle this; modifying the
creationscripts as necessary. It actually has to do this for several functions as well.
The problem is that pg_dump --binary-upgrade intentionally does not simply issue a `CREATE EXTENSION` command the way a
normaldump does, so that it can control the OIDs that are assigned to objects[1]. That means that attempting to
pg_upgradea database with pgtap installed to version 11+ fails trying to create the view that references
pg_proc.proisagg[2].
For pgtap, we should be able to work around this by removing the offending column from the view and embedding the
knowledgein a function. This would be more difficult in other types of extensions though, especially any that are
attemptingto provide more user-friendly views of catalog tables.
I don’t recall why pg_upgrade wants to control OIDs… don’t we re-create all catalog entries for user objects from
scratch?
1: https://www.postgresql.org/message-id/AANLkTimm1c64=xkdpz5ji7Q-rH69zd3cMewmRpkH0WSf@mail.gmail.com
2: https://github.com/theory/pgtap/issues/201