Bruce,
So, one idea would be, instead of a cast, have pg_migrator rebuild the
tsvector columns with ALTER TABLE, so then the 8.4 index code could be
used. But then we might as well just tell the users to migrate the
tsvector tables themselves, which is how pg_migrator behaves now.
It would be nice to have pg_migrator handle this, especially if we could
do it in parallel. Then we just have to warn users that migrating a
database with tsvector columns takes significantly longer. That is,
1) do rest of catalog swap and link/copy of objects.
2) mark all tsvector columns as 83_tsvector and add new tsvector type
(these columns will be unusable for queries)
3) bring up database
4) search for all 83_tsvector columns
5) do ALTER TABLE on each of these columns, in parallel, up to a
configuration setting (default 3).
However, I can also understand not having time to implement the above
before 8.4 release.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
