On Mon, Aug 25, 2014 at 02:15:18PM -0400, Bruce Momjian wrote:
> On Mon, Aug 25, 2014 at 06:34:12AM -0700, Kevin Grittner wrote:
> > Bernd Helmle <mailings@oopsware.de> wrote:
> > > Magnus Hagander <magnus@hagander.net> wrote:
> >
> > >>> I vote for discarding 8.3 support in pg_upgrade. There are already
> > >>> enough limitations on pg_upgrade from pre-8.4 to make it of questionable
> > >>> value; if it's going to create problems like this, it's time to cut the
> > >>> rope.
> > >>
> > >> +1. 8.3 has been unsupported for a fairly long time now, and you can
> > >> still do a two-step upgrade if you're on that old a version.
> > >
> > > Also +1 from my side. I've seen some old 8.3 installations at customers,
> > > still, but they aren't large and can easily be upgraded with a two step
> > > upgrade.
> >
> > +1
> >
> > If we could leave it without it being any extra work, fine; but
> > once a release is over a year out of support, if it's a matter of
> > putting extra work on the pg hackers or on the users who have
> > chosen to wait more than a year after support ends to do the
> > upgrade, I'm OK with asking those users to do a two-phase upgrade
> > or fall back to pg_dump. It's not like we're leaving them without
> > any options.
>
> 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.
I will modify pg_upgrade in three steps:
o remove 8.3 support
o use a single CTE rather than use a temp table
o harden the backend to prevent automatic oid assignment
This is all for 9.5.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +
