Re: pg_migrator to /contrib in a later 9.0 beta

Bruce Momjian wrote:
> As a summary, let me list the migrations pg_migrator supports:
>     8.3 -> 8.4
>     8.4 -> 9.0
>     8.3 -> 9.0
> Surprisingly, it is 8.3 -> 8.4 that has the most restrictions because it
> doesn't have access to the features we added in Postgres 9.0.
> Tom is right that the code could be cleaned up if we removed 8.3 -> 8.4,
> but more importantly the documentation would be clearer.
>   

I think it's extremely valuable that either 8.3 or 8.4 can be upgraded 
to 9.0.  But let's face it:  in the long run, the number of people who 
are going to use pg_migrator for a 8.3->8.4 migration, but that's 
haven't already done so, is a small user base.  The feature set 
improvement in 8.4 had a lot of great stuff, but few that were 
compelling from a "now I can do something completely impossible before!" 
standpoint.  As was noted recently during the "Native DB replication for 
PG" discussion over on pgsql-general last week, there are plenty of 
people happily running a stable 8.3 who just ignore 8.4 altogether for 
that reason.

The replication features in 9.0 are compelling in that way though, and I 
expect to see plenty of upgrades to that version from both 8.3 and 8.4 
installs.  If that works fine right now, I would prefer to see that 
documented as a special case two-versions at once situation that people 
shouldn't necessarily expect in the future, but certainly valuable to 
keep going if the maintenance burden isn't so bad.

Balancing out development reality with the ideal situation from the 
perspective of [potential|current] customers that I deal with every day, 
what I would prefer to see here is:

1) Commit a streamlined pg_migrator that only handles conversions with 
9.0 as a target into contrib, and ship it with 9.0.  Like Bruce, I had 
presumed that the discussion about whether that was going to happen 
would happen in parallel with beta (read:  right now), rather than its 
already being too late to even consider.  I think it's completely 
bizarre from an advocacy standpoint to even consider that you wouldn't 
ship such a tool with the core database, now that it's been around for 
long enough to have a positive track record.

2) Deprecate the pg_migrator hosted on pg_foundry as only being 
recommended for limited 8.3->8.4 upgrades.  Essentially stop active 
development on the version there, and focus on the one in contrib/ 
instead.  People who want an improved 8.3->8.4 tool can always contract 
with someone to backport fixes needed for their particular use case.  I 
think we're past the point where the community at large (meaning:  
mainly Bruce right now) should be expected to do that, now that 9.0 is 
coming out, so long as 8.3 to 9.0 conversions are available too.  I 
can't imagine suggesting to anyone that they upgrade in-place from 8.3 
to 8.4 right now.  Everybody I talk to who isn't already on 8.4 is 
delaying upgrades in anticipation of 9.0 later this year or early next.

My main issues with this project continuing to be hosted in pgfoundry are:

1) Perceived lack of confidence and/or legitimacy for it as an in-place 
upgrade solution, which would be a terrible PR move.  When people ask 
about in-place upgrades and I tell them "there's a tool you can download 
for that", they look at me in terror and ask if I'm serious that it 
isn't just included in the core code.  The improvement between answering 
that way and saying "yes, the tool for 8.3 and 8.4 is included with the 
core distribution", from the perspective of selling people on adopting 
PostgreSQL, cannot be overstated.

2) Anyone who looks at pgfoundry for more than a few minutes walks away 
covered with the scent of dead projects.  One reason for that is that 
related to how painful it is to develop there.  I don't want to reignite 
a full anti-pgfoundry discussion here.  Suffice it to say that there are 
many of us who just can't bear working with CVS anymore who have just 
given up on doing anything useful to projects hosted there.  Something 
that's in core (and therefore included in the git conversion already 
being published) is much easier to work with and submit patches 
against.  I'm already dumping git clones of the PG repo on every system 
I do serious work on.  If each of those were then capable of generating 
pg_migrator patches I could submit, I would actually do that each time I 
use the tool for an upgrade and notice how it could be improved.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us