Re: pg_migrator and an 8.3-compatible tsvector data type
От | Robert Haas |
---|---|
Тема | Re: pg_migrator and an 8.3-compatible tsvector data type |
Дата | |
Msg-id | 603c8f070906010839l3e99d46aofda959685a10407c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_migrator and an 8.3-compatible tsvector data type (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_migrator and an 8.3-compatible tsvector data
type
|
Список | pgsql-hackers |
On Mon, Jun 1, 2009 at 11:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. I agree. I remain doubtful that dumping and reloading the schema is the best way to go, but it's certainly a worthwhile experiment, because (a) I might easily be wrong and (b) we'll hopefully learn some things that will be useful going forward. ...Robert
В списке pgsql-hackers по дате отправления: