Dimitri Fontaine <dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers