=?ISO-8859-1?Q?Anssi_K=E4=E4ri=E4inen?= <anssi.kaariai...@thl.fi> writes:
> The above command assumes there is only one unpackaged version from
> which users might update from. Is that what is wanted? I am wondering if
> FROM OLD should be FROM OLD VERSION version (or better: FROM UNPACKAGED
> VERSION version). This would also solve how to name the old version(s).
> Author decides.
Yeah, that's an interesting point. I don't think that there are any
contrib modules for which we'd bother with such a thing, but it's easily
possible that PostGIS or other third parties would be interested in
supporting direct upgrades from older versions of their modules.
I did actually have a scheme in mind whereby somebody could do that if
they had to given my proposal of yesterday, but I won't bore you with
the details because it was a crock. Thinking about the problem this
morning, I came to the same solution you did, although I was thinking
of a slightly more compact syntax:
CREATE EXTENSION foo [ VERSION targetversion ] [ FROM oldversion ]
The presence of FROM causes us to run foo-oldversion-targetversion.sql
instead of foo-targetversion.sql. As before, that script would consist
mostly of ALTER EXTENSION ADD rather than CREATE commands. What this
means is we aren't hard-wiring any specific name for "pre extension"
versions, and we aren't restricting the author to support updating from
only one old version.
The main risk factor I can see here is that users might give the wrong
old version parameter, causing the system to try to run a script that
was meant for updating some post-extensioning version instead of
pre-extensioning (ie, "CREATE EXTENSION foo FROM '1.0'" when the right
thing would have been "CREATE EXTENSION foo FROM 'old'"). I think
however that we can live with that risk, on two grounds:
1. If you pick the wrong FROM version, the upgrade script will almost
certainly fail, because the objects won't exist or won't be in the state
it expects (ie, not already members of the extension).
2. The main use for this feature will be early in the lifespan of
extensions, when there aren't going to be many post-extension upgrade
scripts around to pose a risk of confusion. By the time there's really
much risk of people making this mistake, it won't matter anymore.
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
