Re: pg_dump versus ancient server versions

Anyway, to get back to the original point ...

No one has spoken against moving up the cutoff for pg_dump support,
so I did a very quick pass to see how much code could be removed.
The answer is right about 1000 lines, counting both pg_dump and
pg_upgrade, so it seems like it's worth doing independently of the
unnest() issue.

The attached is just draft-quality, because I don't really want
to pursue the point until after committing the pg_dump changes
being discussed in the other thread. If I push this first it'll
break a lot of those patches. (Admittedly, pushing those first
will break this one, but this one is a lot easier to re-do.)

BTW, while looking at pg_upgrade I chanced to notice
check_for_isn_and_int8_passing_mismatch(), which seems like it's
not well thought out at all. It's right that contrib/isn will
not upgrade nicely if the target cluster has a different
float8_pass_by_value setting from the source. What's wrong is
the assumption that no other extension has the same issue.
We invented and publicized the "LIKE type" option for CREATE TYPE
precisely so that people could build types that act just like isn,
so it seems pretty foolish to imagine that no one has done so.

I think we should nuke check_for_isn_and_int8_passing_mismatch()
and just refuse to upgrade if float8_pass_by_value differs, full stop.
I can see little practical need to allow that case.

regards, tom lane