Re: pg_migrator to /contrib in a later 9.0 beta

Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
> >> A lot of people are not willing to put stuff labeled "contrib" on
> >> their production boxes.
> >> 
> >> And as Tom says, even we *ourselves* acknowledge that things in
> >> /contrib are held to a lower standard. If we put that label on
> >> pg_migrator, it doesn't exactly signal people that this is something
> >> they should use on their critical database.
> 
> > Well, I guess that begs the question...  IS this something they should
> > use on their critical database?
> 
> Not unless it gets some serious testing during the 9.0 beta cycle.
> Which it surely won't get if it's not included in the core tarball.
> 
> I think that having it in contrib for a release cycle or so would be
> exactly the right approach, actually.  Peter's position that it should
> be in /bin is fine *once the bugs are out*.  Just dropping it there
> doesn't make the bugs go away.

I think one aspect we might be missing is that /contrib has uses beyond
experimental stuff.  For example, I don't believe anyone thinks
/contrib/pgcrypto is going to get more stable than it is now, but it is
in /contrib because it has functionality that is useful to a limited
number of users.  I think these /contrib modules fall into a similar
category:

auto_explain/fuzzystrmatch/hstore/isn/oid2name/pageinspect/pg_buffercache/pg_freespacemap/pg_standby/pg_stat_statements/pgbench/pgrowlocks/pgstattuple/sslinfo/unaccent/

That is over a third of the /contrib modules.  I think pg_migrator falls
into that category too --- it is only of use to people wanting to do a
binary upgrade, and even then, they only run it once.  And it is not
something you are going to just fire up like psql.  Here is the
pg_migrator README:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pg-migrator/pg_migrator/README?rev=1.72&content-type=text/plain

and the 15-step INSTALL file:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/~checkout~/pg-migrator/pg_migrator/INSTALL?rev=1.56&content-type=text/plain
  
 

While most of the limitations in previous versions of pg_migrator are
gone, there are still issues with migrating /contrib modules, and there
are many steps to its use.  

I think to attain mass usage of pg_migrator, some type of one-click
installer has to be built that can access the operating system and make
the migration process simple, though that is probably beyond what we as
a community are going to do.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com