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

From Tom Lane
Subject Re: pg_migrator and an 8.3-compatible tsvector data type
Date
Msg-id 17782.1243869510@sss.pgh.pa.us
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  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greg Stark <stark@enterprisedb.com> writes:
> On Mon, Jun 1, 2009 at 4:03 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> We really need to figure out an approach that lets us keep the old
>> datatypes around under a different name while making the original name
>> be the new version of the datatype. �That way people can migrate and
>> be up, and deal with the need to rewrite their tables at a later time.

> I do agree that having to rewrite the whole table isn't really
> "upgrade-in-place".

It's certainly the case that there is a lot more work to do before
pg_migrator could support everything that we reasonably want to be
able to do in a version update.  As I see it, the reason it's getting
revived now is that 8.3->8.4 happens to be an update where most of what
it can't (yet) do isn't necessary.  That means we can get it out there,
get the bugs out of the functionality it does have, and most importantly
try to set an expectation that future updates will also have some degree
of update-in-place capability.  If we wait till it's perfect then
nothing will ever happen at all in this space.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type
Next
From: Aidan Van Dyk
Date:
Subject: Re: pg_standby -l might destory the archived file