Re: obsoleting plpython2u and defaulting plpythonu to plpython3u

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: obsoleting plpython2u and defaulting plpythonu to plpython3u
Дата
Msg-id 20180427173732.alsxuyjigv7o3iaq@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: obsoleting plpython2u and defaulting plpythonu to plpython3u  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 2018-04-27 13:34:58 -0400, Tom Lane wrote:
> Yeah, there's a separate set of questions about what happens during
> pg_upgrade of a database containing the existing plpythonu extension.
> 
> You could imagine hacking the dump/reload case by defining plpythonu
> as an empty extension with a dependency on plpython2u (or, maybe
> someday in future, a dependency on plpython3u).  But that won't do
> the trick for binary upgrades; we might need special-case code in
> pg_dump/pg_upgrade to fix that.

One way to deal with that is have an upgrade script that does the
reassignment. Seems a mite cleaner than doing it in pg_dump. We could
just have a query updating pg_depend to reference the new extension
rather than the old.  That'd mean we'd be in the "old" situation before
somebody an extension update ran, but that seems hard to avoid?

Greetings,

Andres Freund


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: obsoleting plpython2u and defaulting plpythonu to plpython3u
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Toast issues with OldestXmin going backwards