Re: pg_migrator and an 8.3-compatible tsvector data type
От | Dimitri Fontaine |
---|---|
Тема | Re: pg_migrator and an 8.3-compatible tsvector data type |
Дата | |
Msg-id | 26E00E21-3145-41C8-B8B1-CD193627FB9F@hi-media.com обсуждение исходный текст |
Ответ на | Re: pg_migrator and an 8.3-compatible tsvector data type (Greg Stark <stark@enterprisedb.com>) |
Ответы |
Re: pg_migrator and an 8.3-compatible tsvector data
type
|
Список | pgsql-hackers |
Hi, Le 30 mai 09 à 16:02, Greg Stark a écrit : > On Sat, May 30, 2009 at 1:11 PM, Bruce Momjian <bruce@momjian.us> > wrote: >> I have discovered a simpler solution using ALTER TABLE and calling a >> conversion function: >> >> test=> CREATE TABLE tsvector_test(x tsvector); >> CREATE TABLE >> test=> ALTER TABLE tsvector_test ALTER COLUMN x TYPE tsvector >> test-> USING conversion_func(x); >> ALTER TABLE >> >> No need for a fake data type and the required index infrastructure. > > I assume you're putting this in the list of commands to run > post-migration along with any reindex commands etc? Because it will > take a while (still faster than dump/reload i think). Just thinking some more about the idea to get all those post- processing steps running in parallel, it's occurring to me that we have all we need already: would it be possible for pg_migrator to issue a schema only script with a catalog, in the custom archive format? Then we could use pg_restore -j <whatever> post_migrator.script to run the last migration step. Of course, people will want the custom script output of pg_migrator to be optional, I guess. Regards, -- dim
В списке pgsql-hackers по дате отправления: