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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
