Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> I'm in the middle of catching-up with pgsql-general and I see several
> confused users about how to upgrade directly from 8.4. As Tom said, we
> could easily provide upgrade scripts to handle the move, we just
> didn't, so there's some more manual work to do.
> I'm wondering how much work that really is — I had a SQL query that was
> good at preparing the extension--unpackaged--1.0.sql script, so I could
> use that to produce a set of extension--unpackaged-in-8.4--1.0.sql ones.
> Now, should I get to do that, would that be accepted into PostgreSQL
> itself in, say, 9.1.2? If not, I have to think about how to distribute
> that, and depending on how to, if there's any value doing that for our
> users.
I think it would be worth looking at just how messy they'd be. We
failed to think about supporting the direct-from-8.4 case at all, but in
hindsight we really should have.
I guess one question that needs to be answered is "why stop at 8.4"?
I don't think we want to contract to support direct upgrades from every
previous contrib version ... but ...
An important point here is that a lot of existing installations may be
on $version and yet have a set of SQL objects for a particular contrib
module that represent $previous_version. Given the lack of easy upgrade
methods in the pre-extensions world, it's not too unlikely that such
situations are the majority :-(. So we need to factor that problem into
both our evaluations of how useful additional upgrade scripts are, and
how we're going to document which one to use.
We could avoid the documentation problem if the update-from-unpackaged
scripts could be designed so that they Just Work with multiple previous
versions of the contrib module. In at least some cases, such as a new
function that wasn't there before, I think this would be quite easy
to do --- just use CREATE OR REPLACE FUNCTION. Many of the contrib
modules haven't really changed much recently, so we shouldn't dismiss
this as impractical without taking a look.
regards, tom lane