Re: Extension Templates S03E11

Поиск
Список
Период
Сортировка
От Tom Dunstan
Тема Re: Extension Templates S03E11
Дата
Msg-id CAPPfruy1QgRV7MEDgVjTHB9a=STduvzNwz_oLYz=5LJ1VvOEoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extension Templates S03E11  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Extension Templates S03E11
Список pgsql-hackers
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. We have an extension mechanism now, and a distribution
mechanism (which people may or may not like, personally I'd still
rather install rpms) so why do we still need to ship these things as a
blessed bundle which is tied to a specific release?

If things were split out, it would be much easier for extension
authors to maintain branches targeting different major versions of
pgsql. Users could then upgrade those separately from upgrading the
major db version.

If this were considered seriously, we could still package up a contrib
tarball with the same set as we have now, and for testing we could
either teach the buildfarm client to pull the contrib modules from
their respective homes, or replace the contrib dirs with git submodule
refs.

I suppose there's a case to be made that there will always be some
extensions which are inseparable - plpgsql is the obvious case - but
we do go to a fair bit of effort to keep backward compatibility in
that case. So the version number issue isn't as much of a deal. Most
extensions we'd expect to be more fluid, and we'd expect users to
upgrade at (perhaps) a different rate to the main db. Is there a case
for a small number of "built-in" extensions being versionless, but
everything else requiring a version number AND dumping out with the
version number?

Cheers

Tom



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Dunstan
Дата:
Сообщение: Re: Proposed feature: Selective Foreign Keys
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extension Templates S03E11