Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: David E. WheelerDate: 2009-07-23 06:46:38
Subject: Re: Extension Facility
Previous:From: David E. WheelerDate: 2009-07-23 06:41:22
Subject: Re: revised hstore patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group