Hardening pg_upgrade

Now that everyone is happy with how pg_upgrade_support uses global
variables to set preserved oids (or at least has no better ideas), I
think it is time to lock down this usage to prevent future breakage.

Specifically, the first attached patch causes pg_upgrade_support
functions to throw errors when called by a backend that is not in binary
upgrade mode.  (This seems like a good safety measure.)  Second, and
more importantly, the patch prevents automatic oid assignment when in
binary upgrade mode, except for temporary objects.  This is to help
guarantee that system-assigned oids do not conflict with preserved oids.

I had to make an exception for temporary tables because pg_upgrade uses
temporary tables to collect schema information.  I tried writing the
query to use CTEs (second patch), but I would then have to have one
query for 8.3, which doesn't support CTEs, and another for 8.4+, plus
the CTE query was more complex than I liked.  Another idea would be to
drop 8.3 support (and remove lots of code to support that), but the
recent large increase in the number of people upgrading from 8.4 makes
that unattractive.  (8.3 did use a different timestamp storage format
though.)

(Of course, the assumption is that temporary tables will not exist at
the time you are assigning preserved oids.)

Barring objections, I plan to apply the first patch to head, and discard
the second patch.

FYI, I think the macro isTempOrToastNamespace() is misnamed --- it is
testing for temporary tables or temporary toast tables, not for any
toast table.  Seems it should be called isTempOrToastTempNamespace(). 
Should I rename it in a separate commit?

-- 
  Bruce Momjian          http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +