Extension Packaging

Hackers,

I finally got round to updating a couple of my extensions to support 9.1 extensions. Unlike the contrib extensions, these needed to target older versions of PostgreSQL, as well. Case in point, the semver data type; you might find the Makefile of 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 contortions necessary to support both 9.1 migration scripts and traditional installation scripts. No need to go into detail on 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 been moved from users/DBAs to extension developers. That said, there are a couple of things that would substantially ease the 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 distributing sql/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 file name with no version in it was considered the same as the default version, then the Makefile could go back to being much simpler (almost; see next point). That is, I'd install semver.sql on >= 9.1 and on < 9.1. I wouldn't have to check what version 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 maintain and 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 would not.

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 version in 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 adding existing objects to an extension package? I realize this means that the term "unpackaged" would have to be reserved and treated specially, and that this is, really, a temporary issue (for perhaps five years), but still, it would ease things in the short term, and I'm not sure how likely it is anyone would want to use "unpackaged" for a version number, anyway.

* Another, minor point: If I release a new version with no changes to the code (as I've done today, just changing the make stuff and documentation), it's kind of annoying that I'd need to have a migration script from the old version to the new 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: “No changes.”

Anyway, those are just my thoughts. Comments?

Best,

David