Re: pg_upgrade(?) not cleaning up old extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade(?) not cleaning up old extensions
Дата
Msg-id 191204.1612631344@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_upgrade(?) not cleaning up old extensions  (Thomas Kellerer <shammat@gmx.net>)
Ответы Re: pg_upgrade(?) not cleaning up old extensions  (Thomas Kellerer <shammat@gmx.net>)
Список pgsql-admin
Thomas Kellerer <shammat@gmx.net> writes:
> I have noticed that when I look at pg_available_extensions many extensions are listed with multiple versions even
thoughonly the latest one is actually used. 

Yes, that view is supposed to list the versions that are available
to be installed.  Typically, installation scripts for several back
versions exist on disk.  This is an artifact of the way that we
approach providing extension upgrade capability, but it can be handy
if you want to test SQL code against back versions.

As an example, contrib/adminpack installs

adminpack--1.0.sql
adminpack--1.0--1.1.sql
adminpack--1.1--2.0.sql
adminpack--2.0--2.1.sql

Ordinarily, when you "create extension adminpack", it runs all four
of those scripts in sequence and you end up with the 2.1 SQL objects.
But if you ask to install some earlier version, it just stops after
the appropriate script.  So pg_available_extensions shows 1.0, 1.1,
2.0, and 2.1 as available versions.  (Of course, the main reason
for having the delta scripts is to support "alter extension upgrade".)

            regards, tom lane



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

Предыдущее
От: Victor Sudakov
Дата:
Сообщение: Re: wal-g (https://github.com/wal-g/wal-g) reliability
Следующее
От: bayapa thippaluri
Дата:
Сообщение: Reg: Required postgresql 12 version pg_rewind steps