* 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
