"David E. Wheeler" <david@kineticode.com> writes:
> On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
>> How do you select which upgrade script to apply?
> You run all those that contain version numbers higher than the currently-installed one.
> This of course assumes that one can correctly tell that one version number is higher than another.
This idea is not exactly free of disadvantages.
1. It assumes that the underlying .so supports not only the current
version, but every intermediate version of the SQL objects. For
example, say the previously installed version was 1.10, and we are
trying to go to 1.12. With your proposal we must pass through the
catalog state applicable to 1.11. What if that includes some SQL
function whose underlying C function is no longer there? The
CREATE FUNCTION command will fail, that's what, even though the
next update file would have deleted it or more likely replaced it
with a reference to some other underlying function.
2. It can't tell whether a missing update file means "no work is
required" or "no upgrade is possible"; in fact, without quite a lot of
assumptions about version numbers, it can't even tell that an
intermediate version update file is missing at all. I assume you expect
that the backend would treat a missing file as "no work is required",
but that carries a lot of risk of winding up in a bad state if a file
fails to get installed or fails to get read for some reason.
I'd much rather expect the extension author to explicitly support each
pair of (from, to) version numbers that he's prepared to deal with.
If he can build those update scripts as simple concatenations of
single-step scripts, great; but let's not hard-wire the assumption that
that approach MUST work.
regards, tom lane