Andrew Dunstan wrote:
> > I can't imagine losing a huge percentage of pg_migrator users via hstore
> > changes, especially since you can migrate hstore manually and still use
> > pg_migrator.
> >
> >
>
> We could finesse the hstore issues, but we are already blown out of the
> water right now by the enum issue. My biggest end client has been
> replacing small lookup tables with enums ever since they migrated to 8.3
> many months ago. Another end client is currently moving to implement FTS
Ah, yea, enum is an issue.
> on 8.4, and they will be hit by the tsvector/GIN restrictions in the
> future unless we fix that. All I was saying is that the more such
FTS will be fine for migration from 8.4 to 8.5; it was only the
internal format change that caused FTS migration not to work from 8.3 to
8.4 (index rebuild required). There is nothing about FTS that prevents
migration.
Here is the pg_migrator README with the restrictions:
http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pg-migrator/pg_migrator/README?rev=1.56&content-type=text/x-cvsweb-markup
I will need to document that many of these are 8.3-8.4-only migration
issues.
> restrictions there are the less people will be able to use the tool.
> Surely that is undeniable. I think it's great we (i.e. you) have made a
> start on this, but there is a long way to go.
Yes, I just don't want pg_migrator to be seen as a "complainer" and
something that is always a drag on progress. Even if we had no data
format change, using pg_migrator is still a 14-step process, so my guess
is that only people with large databases where dump/reload is
unreasonably long will use it, and in such cases, having to manually
migrate some items is probably acceptable.
What is important for me is that when pg_migrator succeeds, it is
reliable, and when it can't migrate something, it is clear.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
