Re: pg_upgrade + Extensions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade + Extensions
Дата
Msg-id 655.1441065504@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_upgrade + Extensions  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_upgrade + Extensions  ("David E. Wheeler" <david@justatheory.com>)
Список pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 08/31/2015 07:32 PM, Bruce Momjian wrote:
>> Still, I don't know how many people are doing this, but the right fix is
>> to get the names of the modules that are superceeded and tell pg_upgrade
>> to skip them.

> I don't think this knowledge should be hardcoded in pg_upgrade. I could 
> see some point in a switch that would tell pg_upgrade a list of 
> extensions to ignore.

That would not be terribly helpful for cases where the pg_upgrade call is
embedded in some wrapper script or other.

In any case, there is plenty of precedent for hard-coding knowledge about
specific version updates into pg_upgrade.  The question here is whether
it's feasible to handle extensions that way.  I think we could reasonably
expect to know about cases where a formerly separate extension got
integrated into core, but are there other cases where pg_upgrade would
need to ignore an extension in the old database?
        regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_upgrade + Extensions
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: pg_upgrade + Extensions