Extension Packaging

Hackers,

I finally got round to updating a couple of my extensions to support 9.1 extensions. Unlike the contrib extensions,
theseneeded to target older versions of PostgreSQL, as well. Case in point, the semver data type; you might find the
Makefileof particular interest: 
 https://github.com/theory/pg-semver/blob/master/Makefile

Andrew Dunstan helped me figure out how to get this working, but I have to say, I'm less than thrilled at the
contortionsnecessary to support both 9.1 migration scripts and traditional installation scripts. No need to go into
detailon it, really; you can see it in that Makefile or read about it on the PGXN blog. 
 http://blog.pgxn.org/post/4783001135/extension-makefiles

I'm really thrilled with the extensions stuff. It makes it about as easy as possible for users to add them to their
database.And I think it's entirely appropriate that the complexity of managing extension upgrades between versions has
beenmoved from users/DBAs to extension developers. That said, there are a couple of things that would substantially
easethe the load for developers: 

* I would love to be able to maintain a single file for the default version of an extension. So rather than
distributingsql/semver--0.2.2.sql or, as I've done in the Makefile, copy sql/semver.sql to sql/semver--0.1.2.sql, if a
filename with no version in it was considered the same as the default version, then the Makefile could go back to being
muchsimpler (almost; see next point). That is, I'd install semver.sql on >= 9.1 and on < 9.1. I wouldn't have to check
whatversion I was installing against in the Makefile and do something different, which, frankly, is ugly and
error-prone.

* For the special unpackaged script, I'd like to be able to do something similar. At first I thought I could just
maintainand distribute a sql/semver--unpackaged--0.1.2.sql file and, beyond that, regular migration scrips would handle
things.But then, if someone installed 0.1.3 against 9.0, then upgraded to 9.1 and then issued `CREATE EXTENSION FROM
unpackaged`,then everything that was in 0.1.2 would be added to the extension package, but anything added in 0.1.3
wouldnot. 

So what I've done instead is maintain a file, sql/semver--unpackaged.sql, and I copy it to a file named for the current
versionin the Makefile. So this will just be kept up-to-date with the latest version, and will always be installed as
semver--unpackaged--$defaul_version.sql.But I sure wish I didn't have to do that. 

What if, instead, I could just install semver--unpackaged.sql, and the extension system knew that this one was for
addingexisting objects to an extension package? I realize this means that the term "unpackaged" would have to be
reservedand treated specially, and that this is, really, a temporary issue (for perhaps five years), but still, it
wouldease things in the short term, and I'm not sure how likely it is anyone would want to use "unpackaged" for a
versionnumber, anyway. 

* Another, minor point: If I release a new version with no changes to the code (as I've done today, just changing the
makestuff and documentation), it's kind of annoying that I'd need to have a migration script from the old version to
thenew version that's…empty. But I dunno, maybe not such a big deal. It's useful to have it there with a comment in it:
“Nochanges.” 

Anyway, those are just my thoughts. Comments?

Best,

David