Re: Removing pg_migrator limitations

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane