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
ofa 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
extensionsas low as is reasonably possible.
Best,
David