Tom Lane wrote:
> Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
