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
maintenancework for a rapidly-evolving extension. I doubt I would ever have got very far with pgTAP if I'd had to do
somethinglike this.
Best,
David