formrdesc() versus relation rowtype OIDs

While researching the RelationCacheInitializePhase2 unpleasantness,
I happened across this long-ago discussion:
http://archives.postgresql.org/pgsql-bugs/2004-12/msg00128.php
in which we established the coding rule that formrdesc() must construct
completely-correct TupleDescs for the relations it builds, even though
it's allowed to get away with a lot of omissions in other respects.
The reason is that the tupdesc may get copied into the catcaches
before RelationCacheInitializePhase2 has a chance to correct anything.

This struck me because I realized that I'd broken it in the recent
patches to eliminate the pg_database flat files :-(. Specifically,
formrdesc now supposes that it can leave tdtypeid set to RECORDOID
and RelationCacheInitializePhase2 will fix it. The reason I changed
that was that we now need to be able to use formrdesc for pg_database,
and pg_database doesn't have a hard-wired pg_type OID for its rowtype
because it isn't a "bootstrap" catalog. So that means that tdtypeid
might be wrong in the catcache entries for the core catalogs that
formrdesc is used for.

Now as far as I can see, this has no immediate consequences because
catcaches' cc_tupdescs are never used in a way that would make their
tdtypeid important. But it seems like the kind of thing that could
come back to haunt us someday.

The possible responses seem to be:

1. Leave it as-is, hope it never matters.

2. Hack up the bootstrap process enough so that we can have a hard-wired
rowtype OID for pg_database, and then revert the changes to formrdesc.

3. Add an API to catcache.c that would let RelationCacheInitializePhase2
(or actually it's RelationCacheInitializePhase3 now) tell catcache.c to
insert the correct rowtype ID into its cached tupdescs, once it finds
out the correct ID.

#3 is pretty ugly but it would be a much more localized fix than #2.

Thoughts, better ideas?

regards, tom lane