From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extension facility (was: revised hstore patch) |
Date: | 2009-07-23 11:49:02 |
Message-ID: | 87eis7bowh.fsf@hi-media-techno.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Jul 23, 2009, at 2:44 AM, "David E. Wheeler" <david(at)kineticode(dot)com>
> wrote:
>>
>> 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.
Well there's already an API for this in the extension design:
create extension foo
...
upgrade function upgrade_foo(old version, new version)
So pg_migrator would have to look on previous cluster for which version
of the module was there and on the new cluster which is installed, and
run the function accordingly...
All the burden is then on the extension's author.
Regards,
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | mahendra chavan | 2009-07-23 12:29:19 | query decorrelation in postgres |
Previous Message | Laurent Laborde | 2009-07-23 11:22:59 | Re: Higher TOAST compression. |