Re: extension facility (was: revised hstore patch)
От | Robert Haas |
---|---|
Тема | Re: extension facility (was: revised hstore patch) |
Дата | |
Msg-id | 5962B730-95CB-4E18-8AFD-0AFCCF35923E@gmail.com обсуждение исходный текст |
Ответ на | Re: extension facility (was: revised hstore patch) ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: extension facility (was: revised hstore patch)
Re: extension facility (was: revised hstore patch) |
Список | pgsql-hackers |
On Jul 23, 2009, at 2:44 AM, "David E. Wheeler" <david@kineticode.com> wrote: > On Jul 22, 2009, at 1:11 PM, Robert Haas wrote: > >> If you keep an old and a new version of the datatype, you can't >> upgrade a tuple at a time, but you can at least upgrade one column at >> a time, which is still better than a kick in the head. > > And as long as you're willing to deprecate how far back you'll go in > doing such updates, thus keeping the maintenance of your code > reasonable over time. Of course. > >> If you make the extension-upgrade facility rewrite everything, you >> have to do your entire cluster in one shot. That will work for some >> people, but not for all. And unless you ship both versions of hstore >> with either PG 8.4 or PG 8.5, you're going to need the conversion to >> be done inside pg_migrator, which introduces a whole new level of >> complexity that I think we'd be better off without. > > Well, it depends. If there could be some sort of defined interface > for pg_migrator could call to migrate any data type (this issue > applies mainly to types, yes?), then an extension author just needs > to implement that interface. No? Yes... but "if" and "just" can paper over a good deal of complexity, and it's not clear to me that there's any compensating advantage. ...Robert
В списке pgsql-hackers по дате отправления: