Re: extension facility (was: revised hstore patch)

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

In response to

Responses

Browse pgsql-hackers by date

  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