On Jul 23, 2009, at 2:44 AM, "David E. Wheeler" <david(at)kineticode(dot)com>
> 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.
>> 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.
In response to
pgsql-hackers by date
|Next:||From: Laurent Laborde||Date: 2009-07-23 11:22:59|
|Subject: Re: Higher TOAST compression.|
|Previous:||From: Richard Huxton||Date: 2009-07-23 10:50:02|
|Subject: Re: Extensions User Design|