Re: ALTER EXTENSION UPGRADE, v3

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Let me summarize the prospective solutions based on some chatting with
> some potential extension authors (that is, folks who maintain in-house
> stuff they're thinking of offering as extensions). Especially since I
> think at this point the majority of -hackers has lost track of the argument:

Thanks for doing that!

> (A) Writing a separate upgrade script between each two versions

> (B) As (A), but with in-script Includes so that eariler versions of
> scripts could be re-used for later version upgrades or strung together.

Well if you want to support upgrades between each two versions, that
means you have users and you don't know what they currently have
installed. Then you have this problem to solve, and it's complex the
same no matter what tools are offered.

> (C) as (A), but through concatinating scripts for upgrade using Make
> files. This seems like the worst of all possible solutions. First, it
> prevents us from ever having a binary module release network, and
> permanently requires anyone using extensions to have GNU make present
> and accessible on their system, thus pretty much leaving out the Windows
> users forever. Second, it's a lot harder for module maintainers to
> tweak than includes would be, especially for SQL-only modules. Third,
> it requires Make to check what version you currently have installed in
> order to build the module, something which is unlikely to be reliable.

You're missing something here. In this scheme, make is only used to
prepare the upgrade scripts. Then you package and ship those, and you
don't need make no more, even when the target is windows. More than
that, the tool to use would be `cat`, really, Make would just call it on
files in the right order. A perl one-liner will certainly do just fine.

So in fact this is just saying the authors to manage the situation as
they wish, then setup the control file with the produced scripts
references to use. That's it.

> (D) Requires a series of ordered upgrade scripts in sortable version
> numbering, each of which gets applied in order between the two versions.

Well, your build process is certainly powerful enough to concatenate
file content together, right?

> Note that handling upgrades of complex applications is not a problem
> which anyone in the world has solved that I know of. So it's
> unsurprising that we're having difficulty with it.

Agreed. So my proposal was, again, that we don't solve it this year but
provide a mechanism that allows extension authors to setup which script
to run when the user will ALTER EXTENSION foo UPGRADE. How they come up
with such a script, I say, is *NOT* our problem. At least for 9.1.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support