Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Basically there isn't much extra work to go from 8.3 to 8.4 compared to
> > 8.3 to 8.5.
>
> That might be true today, but it will stop being true once we replace
> the oid/relfilenode management hac^Wcode with the proposed new approach.
>
> > The other problem with moving to /contrib is that I can't put out
> > pg_migrator updates independently of the main community release, which
> > could be bad.
>
> That was a good thing while pg_migrator was in its "wild west"
> development stage. But if you have ambitions that people should trust it
> enough to risk their production DBs on it, then it had better be stable
> enough for this not to be a big drawback.
>
> Also note the point about how it'll be a lot easier to keep it in sync
> with pg_dump and backend behavior if it's only got to work with the
> pg_dump version that's in the same release. Again, the proposed changes
> tie it to a particular pg_dump and target backend version noticeably
> more than it was before; so if you try to keep it separate this is going
> to be an even bigger headache than it already was during the run-up to
> 8.4.
>
> Lastly, getting pg_migrator working reliably would be a sufficiently
> Big Deal that I think a critical pg_migrator bug would be sufficient
> grounds for forcing a minor release, just as we sometimes force a
> release for critical backend bugs.
>
> > I am glad some people think pg_migrator is ready for /contrib.
>
> To be clear, I don't think it's really ready for contrib today. I think
> it could be up to that level by the time 8.5 releases, but we have to
> get serious about it, and stop pretending it's an arm's-length project
> the core project doesn't really care about.
OK, I am convinced.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
