Re: Extensions versus pg_upgrade

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Extensions versus pg_upgrade
Дата
Msg-id AANLkTi=fXV1SFvv+nxj2LR_2Tco7USSduQnWRvOif66c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Extensions versus pg_upgrade  ("David E. Wheeler" <david@kineticode.com>)
Ответы Re: Extensions versus pg_upgrade  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
On Tue, Feb 8, 2011 at 12:57 PM, David E. Wheeler <david@kineticode.com> wrote:
> On Feb 8, 2011, at 9:36 AM, Robert Haas wrote:
>
>> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
>> UPGRADE is pretty much a must-have for a useful feature regardless of
>> this issue.  I had previously thought that we might be able to limp
>> along with half a feature for one release - if you're not actually
>> depending on anything in the extension, you could always drop it and
>> the install the new version.  But the more I think about it, the less
>> realistic that sounds; dependencies on the extension are going to be
>> very common, and while it may be practical to drop and recreate the
>> dependent objects in some cases, it's certainly going to annoy a lot
>> of people.
>
> I was just thinking about the upgrade issue, and was wondering if this was do-able:
>
> * No upgrade scripts. Nothing to concatenate, include, or maintain.
> * No version tracking
>
> Yeah, what I'm saying is, throw out the whole thing. Instead, what would happen is
>
>    ALTER EXTENSION foo UPGRADE;
>
> Would do some trickery behind the scenes to just delete all those objects that are part of the extension (just like
DROPEXTENSION should do), and then run the installation SQL script. So the objects would be exactly as specified in the
installationscript, with no need for the extension maintainer to worry about how to run upgrades, and no need for
PostgreSQLto track version numbers. 
>
> Is this do-able? I recognize that there could be some issues with settings tables and what-not, but surely that's no
differentthan for dump and reload. The question in my mind is whether it would even be possible for the extension code
tounload every bit of an extension and load the new stuff, inside a transaction. 

No, this is not doable, or at least not in a way that provides any
benefit over just dropping and reinstalling.  The problem is that it
is going to fall down all over the place if other objects are
depending on objects provided by the extension.  Like:

CREATE VIEW v AS SELECT extensionfunc(1);

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: postponing some large patches to 9.2
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Extensions versus pg_upgrade