Tom Dunstan <pgsql@tomd.cc> writes:
> On 3 December 2013 02:02, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>>> On the other hand, I can appreciate the concern that we don't really
>>> want a dump/restore to include the extension definition when it's
>>> already on the filesystem. That said, it amazes me that we don't
>>> include the version # of the extension in pg_dump's 'CREATE EXTENSION'
>>> command.. How is that not a problem?
>> Including the version number would be a problem.
>>
>> When you install PostgreSQL 9.1, you only have hstore 1.0.
>> When you install PostgreSQL 9.2, you only have hstore 1.1.
>> When you install PostgreSQL 9.3, you only have hstore 1.2.
> 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,
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).
regards, tom lane
