I have added a new regression test "type_sanity" to perform mechanical
cross-checks on pg_type, pg_class, and related tables. I also greatly
expanded "opr_sanity" to check pg_proc, pg_aggregate, pg_am & friends
as well as checking pg_operator more thoroughly.
This turned up the usual quota of small errors in the tables,
of course ;-)
An annoying limitation on these tests is that they can't enforce
operand type cross-checks (like whether a pg_operator entry has
the same operand and result types as its underlying pg_proc) because
of binary-compatible-type cheats that are being done in a few existing
cases. For now, I have left those checks out of the regression tests.
It would be nice to develop an SQL representation of binary type
compatibility so that those checks could be made cleanly.
Alternatively, we could make multiple entries in pg_proc for any
procedure being used to support multiple types (for example, if
int4eq is also used to implement equality of "oid" then it would need
to be listed again with oid as the input data type). This would only
cost another couple dozen entries in pg_proc, so it might be the best
near-term solution.
(A very short-term answer would be to turn on the checks anyway, and
put the known exception cases into the expected outputs for the tests.
That's pretty ugly, not to mention a pain to maintain, but it might be
a reasonable thing to do if we aren't going to implement a better
solution soon...)
regards, tom lane