Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
I think it's becoming increasingly clear that pg_migrator is not for
the faint of heart; in fact, I think we should hedge references to it
with words like "experimental".
Probably ...
I'm with Robert on that one - while pg_migrator is extremely inmportant
for us to go forward. I really think we need to tag it "experimental"
for this release at least. pg_migrator is complex and we are still
discovering new issues every day I don't think rushing it as _THE_
solution will do any good for our reputation. A lot of our code(as
software in general) took years to mature and pg_migrator is likely not
an exception.
Just to recall the history, the first pgfoundry
commit messages for this tool were on February 9th, three months after
the start of the final CommitFest and feature freeze for 8.4. Since
then, development has proceeded at an amazingly rapid pace, but
there's only so much you can do in four months,
... but the above is a *complete* misrepresentation of the thing's
history (apparently you failed to look in the Attic?). EDB have been
using previous versions of this tool for some years, and the basic
premise is the same as contrib/pg_upgrade that existed as far back as
7.1/7.2 timeframe.
well - how much field exposure has pg_migrator/edb_migrator seen
actually? given the large number of "breaks your database" bugs and
issues that got found during the last few weeks I have a hard time
imaging that edb really used the current code for their customers.
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
