On Mon, Aug 25, 2014 at 03:04:52PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > OK, I will move in the direction of removing 8.3 support and use a
> > single query to pull schema information. I was hesistant to remove 8.3
> > support as I know we have kept pg_dump support all the way back to 7.0,
> > but it seems pg_upgrade need not have the same version requirements.
>
> Not really related, but ... I've been thinking that it's time to rip out
> pg_dump's support for server versions before 7.3 or 7.4. That would let
> us get rid of a lot of klugy code associated with the lack of schemas
> and dependency info in the older versions. It's possible that we should
> move the cutoff even further --- I've not looked closely at how much could
> be removed by dropping versions later than 7.3.
Yeah, it kind of is related, as that was the logic I followed originally
for pg_upgrade, i.e. never remove supported versions --- that has been
overridden.
> Aside from the question of how much old code could be removed, there's the
> salient point of how do we test pg_dump against such old branches? The
> further back you go the harder it is to even build PG on modern platforms,
> and the less likely it will work (I note for example that pre-8.0
> configure doesn't try to use -fwrapv, let alone some of the other switches
> we've found necessary on recent gcc). I've usually tested pg_dump patches
> against old servers by running them against builds I have in captivity on
> my old HPPA box ... but once that dies, I'm *not* looking forward to
> trying to rebuild 7.x on my current machines.
Yes. You could argue that a double-upgrade from 7.0 to 8.0 to 9.4 would
be less buggy than one from 7.0 to 9.4. I agree there is almost zero
testing of very old versions.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
