Robert Haas wrote: > On Sat, May 1, 2010 at 11:42 AM, Tom Lane <t...@sss.pgh.pa.us> 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 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 <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
