Tom Lane wrote:
> Robert Haas <robertmh...@gmail.com> writes:
> > On Sat, May 1, 2010 at 3:32 AM, Magnus Hagander <mag...@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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
