New regress test (was Re: Timespan_div misbehaving?)

Bruce Momjian <maillist@candle.pha.pa.us> wrote a couple weeks ago:
> Tom, would you please take the pg/include/catalog/*.sql files and merge
> them into the regression sanity checks?  They should be in there too. 
> You can remove them once you have moved them over.

I made some progress on this last night, but still need to work on the
other test file from include/catalog/.

There is a new regress test "oidjoins" that checks consistency of all
OID and REGPROC columns in the standard tables.  Basically it looks
for dangling links --- values that do not match any OID in the target
table that the column is supposed to link to.  The test script can be
rebuilt, if the set of columns to check changes, by running the code
in contrib/findoidjoins.  (I thought about just running findoidjoins
as part of the regress test, but it seems unreasonably slow for that.
Also, you really want to eyeball findoidjoins' output before using it,
since the proggie will be misled by OIDs that join to the wrong table.)

I found a dozen or so bogus tuples in several system tables (mostly
pg_amop and pg_aggregate IIRC).  They had OID entries that referred
to OIDs that actually exist ... but are in the wrong table.  For
example some of the amopclaid fields had values that were OIDs of
procs or types instead of opclass rows.  I believe these are leftovers
from some ancient time when those OIDs were being used for something
else.  (Most of the current assignments of those OIDs have to do with
int8, so I know they are relatively new.  Evidently no one ran an
oidjoins check while the OIDs were unused...)

All of the tuples in question were either unused or else referenced
only by other bogus tuples, so I just deleted 'em.  (I'm new to
adding/removing entries in system tables; is there anything else that
needs to be done besides editing include/catalog/pg_*.h?)

Note the oidjoins test will fail until you do an initdb, because of
the aforementioned bogus tuples.
        regards, tom lane