"David E. Wheeler" <david@kineticode.com> writes:
> * I would love to be able to maintain a single file for the default
> version of an extension.
Basically, this wasn't and isn't on the list of considerations. There
has never been any expectation that a contrib module could use the exact
same SQL script for every Postgres version, and indeed one big thrust of
the extensions design has been to make it easy to have different ones.
I'm not interested in kluging things up after the fact to try to somehow
reverse that mindset and make pre-extension-world and post-extension-world
scripts compatible. That looks like long-term pain in return for very
small short-term gain to me.
> * 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.
If you have multiple old versions that you want to support direct
upgrades from, you should *not* use the unvarnished "unpackaged" naming
convention for those upgrade scripts. Use the real version names
instead, and instruct the users that they'd better get it right when
specifying the FROM version. (Or if possible, set up the scripts to
intentionally fail should they be invoked with the wrong previous
version in place --- eg, it's not bad if they fail when trying to
replace an object that's not there.)
Or to put it more succinctly: there is nothing special about the name
"unpackaged".
> * 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.�
If you did not actually change the contents of the install script, you
should not change its version number either.
regards, tom lane
