From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: ALTER EXTENSION UPGRADE, v3 |
Date: | 2011-02-10 19:35:29 |
Message-ID: | 4BCA1E6C-8BA9-4ED7-A639-DA2552FE66BF@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
> I'm not really addressing that in this proposal. You could imagine
> supporting all the extension versions in one .so, or you could have one
> per version (meaning the upgrade scripts would have to CREATE OR REPLACE
> all the C functions to re-point them at a different .so), or mixed
> cases. Right now the PGXS infrastructure would favor the first because
> it has only limited ability to build multiple .so's in one directory;
> but we could think about improving that if there's demand.
>
> Note that you can version a function even within a single .so, for
> example if hstore 1.0 defines foo() one way and hstore 1.1 defines
> it another, you could make the latter point to the C function name
> foo_1_1 while C function foo continues to provide the old behavior.
> You have to at least provide a stub foo (that could just throw error
> if called) for as long as you want to support upgrading from 1.0.
Good enough for me.
> I don't see how that affects my point? You can spell "1.0" as "0.1"
> and "1.1" as "0.2" if you like that kind of numbering, but I don't
> see that that has any real impact. At the end of the day an author is
> going to crank out a series of releases, and if he cares about people
> using those releases for production, he's going to have to provide at
> least a upgrade script to move an existing database from release N to
> release N+1.
Yeah, but given a rapidly-developing extension, that could create a lot of extra work. I don't know that there's much of a way around that, other than concatenating files to build migration scripts from parts (perhaps via `Make` as dim suggested). But it can get complicated pretty fast. My desire here is to keep the barrier to creating PostgreSQL extensions as low as is reasonably possible.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2011-02-10 19:38:22 | Re: Range Type constructors |
Previous Message | Tom Lane | 2011-02-10 19:31:48 | Re: Adding new variables into GUC |