On 3 December 2013 12:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "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,
> or you'd not have been going to 9.3 in the first place. 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).
Well, I was suggesting further down that extensions which we'd like to
consider built-in because they make guarantees about backwards
compatibility should simply be versionless, since we expect a
transparent upgrade, and as you point out the old version isn't likely
to be there. So maybe hstore wasn't a good example. Those should
continue to be dumped without versions.
(The counter argument is that if hstore 1.2 has awesome new features,
why should people wait until the next major version to enjoy them,
unless they depend on something changing in core?)
Extensions in contrib live in a weird place. Totally builtin stuff
should obviously be dumped without versions, and stuff which is
completely separate and follows its own release schedule should
obviously be versioned. I guess we consider all modules in contrib to
offer the same transparent upgrade guarantees as builtins, so they
shouldn't be versioned, but it feels like some of them should be, if
only because some aren't particularly tied in to the backend all that
tightly. But I guess that's a bogus metric, the true metric is whether
we want people to treat them as basically built-in, with the upgrade
guarantees that go along with that.
Cheers
Tom