Re: pg_migrator to /contrib in a later 9.0 beta

Robert Haas wrote:
> On Sat, May 1, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> 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 in the previous iteration of this discussion I had the
> impression that you felt that it wasn't really to the point where it
> even met our standards for /contrib (although, admittedly, it seems
> those are pretty darn low, at least as far as the stuff that's already
> in there goes).  If I misunderstood or if that that's no longer your
> feeling then maybe it makes sense.  But I don't think we should do it

Well, the original suggestion to move pg_migrator to /contrib was that
it would be easier to do per-major-version distributions of pg_migrator.
However, I have code that is pretty clear about what version it is
dealing with, so I am not worried about that.  One concern I had that it
would be harder to make fixes to pg_migrator if it was tied to Postgres
releases.  However, I am no longer worried about that because I have not
made changes to pg_migrator for months.  (Six months ago I was making
major changes to pg_migrator regularly.)

> at this point unless it's as simple as "check it in and ship it".  If
> doing this seems likely to make 9.0 take longer to get out the door,
> then I think we should wait and do it in 9.1 instead.

I can't imagine why pg_migrator would ever delay 9.0  -- it is in
/contrib and everything it needs is already in the backend code.  We
could always rip it back out of /contrib if we wanted to, or disable it.
That's the beauty of /contrib --- it is isolated from the rest of the
system.

I think the big question is whether we want to provide a binary upgrade
facility for Postgres.  If so, pg_migrator is the only facility
currently available, and I can't imagine another option appearing.  I
would love for pg_migrator to be easier to use, but I can't figure out
how that can happen without an external OS-specific installer.

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