Re: extension facility (was: revised hstore patch)

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

In response to

Browse pgsql-hackers by date

  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.