"David E. Wheeler" <da...@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 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.
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 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.
If you did not actually change the contents of the install script, you
should not change its version number either.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
