pg_dump versus ancient server versions

While doing some desultory testing, I realized that the commit
I just pushed (92316a458) broke pg_dump against 8.0 servers:

$ pg_dump -p5480 -s regression
pg_dump: error: schema with OID 11 does not exist

The reason turns out to be something I'd long forgotten about: except
for the few "bootstrap" catalogs, our system catalogs didn't use to
have fixed OIDs. That changed at 7c13781ee, but 8.0 predates that.
So when pg_dump reads a catalog on 8.0, it gets some weird number for
"tableoid", and the logic I just put into common.c's findNamespaceByOid
et al fails to find the resulting DumpableObjects.

So my first thought was just to revert 92316a458 and give up on it as
a bad idea. However ... does anyone actually still care about being
able to dump from such ancient servers? In addition to this issue,
I'm thinking of the discussion at [1] about wanting to use unnest()
in pg_dump, and of what we would need to do instead in pre-8.4 servers
that lack that. Maybe it'd be better to move up pg_dump's minimum
supported server version to 8.4 or 9.0, and along the way whack a
few more lines of its backward-compatibility hacks. If there is
anyone out there still using an 8.x server, they could use its
own pg_dump whenever they get around to migration.

Another idea would be to ignore "tableoid" and instead use the OIDs
we're expecting, but that's way too ugly for my taste, especially
given the rather thin argument for committing 92316a458 at all.

Anyway, I think the default answer is "revert 92316a458 and keep the
compatibility goalposts where they are". But I wanted to open up a
discussion to see if anyone likes the other approach better.

regards, tom lane

[1] https://www.postgresql.org/message-id/20211022055939.z6fihsm7hdzbjttf%40alap3.anarazel.de