Re: pg_migrator and an 8.3-compatible tsvector data type - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 26E00E21-3145-41C8-B8B1-CD193627FB9F@hi-media.com
Whole thread Raw
In response to Re: pg_migrator and an 8.3-compatible tsvector data type  (Greg Stark <stark@enterprisedb.com>)
Responses Re: pg_migrator and an 8.3-compatible tsvector data type  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Next
From: Tom Lane
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type