"David E. Wheeler" <david@kineticode.com> writes:
> +1. I assume there will be some way to build versioned shared object libraries too, then?
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.
>> In this scheme, all the extension scripts are independent. We spent quite
>> a lot of time arguing about ways to avoid duplication of code between
>> scripts, but frankly I'm not convinced that that's worth troubling over.
>> As far as the initial-install scripts go, once you've released 1.0 it's
>> unlikely you'll ever change it again, so the fact that you copied and
>> pasted it as a starting point for 1.1 isn't really a maintenance burden.
> I disagree with this. A lot of dynamic language libraries never get to
> 1.0, and even if they do can go through periods of extensive development
> with major changes from version to version.
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.
regards, tom lane