* 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 certainly don't see extensions (outside of contrib) in the general sense as being either tied to specific PG versions or being required to maintain the same API that they started with on day 1. Thanks, Stephen
signature.asc
Description: Digital signature