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 по дате отправления: