On Dec 10, 2010, at 4:39 PM, Tom Lane wrote: > 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.
Yes, I always forget about shared objects, since most of the stuff I do isn't C. > 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. That seems relatively low-risk to me. > 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. This does eliminate the need for the core to mandate a version number scheme, but it could create a *lot* more maintenance work for a rapidly-evolving extension. I doubt I would ever have got very far with pgTAP if I'd had to do something like this. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
