Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > While most of the limitations in previous versions of pg_migrator are > > gone, there are still issues with migrating /contrib modules, and there > > are many steps to its use. > > > I think to attain mass usage of pg_migrator, some type of one-click > > installer has to be built that can access the operating system and make > > the migration process simple, though that is probably beyond what we as > > a community are going to do. > > While the above are true statements, IMO the real gating factor right now > for pg_migrator is that people don't know whether they can trust it. > It won't get over that basic hump without a lot more real-world testing; > and as long as it's a separately distributed project I don't think it'll > get the necessary level of testing. That's why I feel it needs some
Agreed. > time in contrib --- and why I don't have a warm fuzzy feeling about > Peter's proposal to push it directly into the core project. I am unclear why it would be in /bin if it requires 15 steps to run and is run only once by only some users. It seems natural for /contrib, like pgcrypto. > As for the "one click" aspect, I think that that's largely on the heads > of packagers to provide some convenient method of using it. For the RPM > packages, I envision eventually having a "postgresql-migrate" package > that contains pg_migrator, a copy of the version-N-minus-1 postmaster, > and some sort of frontend script. Install, run the script, remove. > But we're a long way from that yet. Yes, that is what is needed eventually. -- 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
