From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dfontaine(at)hi-media(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 |
Subject: | Re: extension facility (was: revised hstore patch) |
Date: | 2009-07-23 06:44:13 |
Message-ID: | 6672F48D-2268-4299-83C6-842CB59B2F56@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-07-23 06:46:38 | Re: Extension Facility |
Previous Message | David E. Wheeler | 2009-07-23 06:41:22 | Re: revised hstore patch |