Re: ALTER EXTENSION UPGRADE, v3

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Stepping back from the implementation details and file naming
> conventions a bit, it seems to me that when you do schema upgrades,
> there are basically three possible things you might want to put in the
> upgrade script:
[...]
> I've managed schema upgrades that went through dozens of versions, and
> making sure that you can correctly upgrade from every previous version
> to v48 is definitely going to be a challenge. David's approach makes
> that a little simpler in some ways, but I think it falls down pretty
> badly on point #3.

Where I agree with you is that we're talking about a complex problem,
and whatever tools we have to handle it will not make it any simpler.
The only thing that maybe could be made simpler is how to write the
solution, not how to design what it is.

> I'd actually be inclined to just have ONE upgrade file and invent some
> kind of meta-language for controlling which statements get executed.

I'm currently unimpressed by the idea of inventing new tools to solve a
fairly common problem. All the more when this syntax is based on SQL
when the problem space is all about composing script files. I see your
proposal is not so much SQL'ish, though.

All in all, I think we should postpone solving this problem to until we
have covered the basis, that is running 1 given determined script to
handle 1 specific upgrade that the DBA is driving. I think my proposal
covers that and avoids painting us into a corner should we ever decide
to walk the extra mile here.

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