"David E. Wheeler" <da...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers