Bruce Momjian wrote:
I can just have pg_migrator detect hstore and require it be removed
before upgrading; we did that already for 8.3 to 8.4 and I am assuming
we will continue to have cases there pg_migrator just will not work.
The more things you exclude the less useful the tool will be. I'm
already fairly sure it will be unusable for all or almost all my clients
who use 8.3.
Sorry to hear that. You have studied the existing limitations in the
README, right?
I think it is important to report cases where pg_migrator doesn't work,
but I don't think we will ever avoid such cases. We can't stop Postgres
from moving forward, so my bet is we are always going to have such cases
where pg_migrator doesn't work.
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
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
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
