On Tue, Dec 3, 2013 at 8:44 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> > On 3 December 2013 02:02, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: >> > ISTM that the real solution to this particular problem is to decouple >> > the extensions that are currently in contrib from a specific postgres >> > version. >> >> "Problem"? It's not a bug that you get hstore 1.2 when you dump from 9.2 >> and reload into 9.3; that's a feature. You wanted an upgrade, presumably, > > I don't buy this argument at *all* and it's not going to fly when we've > got multiple versions of an extension available concurrently. I'm > willing to accept that we have limitations when it comes from a > packaging perspective (today) around extensions but the notion that my > backup utility should intentionally omit information which is required > to restore the database to the same state it was in is ridiculous. > >> or you'd not have been going to 9.3 in the first place. > > This notion that a given major version of PG only ever has one version > of an extension associated with it is *also* wrong and only makes any > sense for contrib extensions- which are the exception rather than the > rule today. > >> The entire reason >> why the extension mechanism works like it does is to allow that sort of >> reasonably-transparent upgrade. It would not be a step forward to break >> that by having pg_dump prevent it (which it would fail to do anyway, >> likely, since the receiving installation might not have 1.1 available >> to install). > > I agree that there should be a way to *allow* such an upgrade to happen > transparently and perhaps we keep it the way it is for contrib > extensions as a historical artifact, but other extensions are > independent of the PG major version and multiple versions will be > available concurrently for them and having pg_dump willfully ignore the > extension version is a receipe for broken backups. > > Step back and consider a user who is just trying to restore his backup > of his 9.2 database into a new server, also with 9.2, as quickly as he > can to get his system online again. Having four different versions of > extension X installed and available for 9.2, no clue or information > about which version was installed into which databases and getting > mysterious failures and errors because they're not all compatible is not > what anyone is going to want to deal with in that situation.
I think Tom's original idea here was that new versions of extensions *shouldn't ever* be backward-incompatible, and therefore if this problem arises it's the extension author's fault. It isn't however clear that this dream is likely to be realized in practice. For example, the only difference between hstore 1.0 and hstore 1.1 is that we dropped the => operator, for the very good reason that we have been slowly working towards deprecating => as an operator name so that we can eventually use it for the purpose that the SQL standard specifies. Given that we've done it in core, we can hardly say that no one will ever do this anywhere else. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
