Re: pg_upgrade from 12 to 13 failes with plpython2
От | Bruce Momjian |
---|---|
Тема | Re: pg_upgrade from 12 to 13 failes with plpython2 |
Дата | |
Msg-id | 20201119042955.GA6414@momjian.us обсуждение исходный текст |
Ответ на | Re: pg_upgrade from 12 to 13 failes with plpython2 (Devrim Gündüz <devrim@gunduz.org>) |
Ответы |
Re: pg_upgrade from 12 to 13 failes with plpython2
|
Список | pgsql-general |
On Wed, Nov 18, 2020 at 10:06:17PM +0000, Devrim Gunduz wrote: > Hi, > > On Wed, 2020-11-18 at 14:54 -0500, Tom Lane wrote: > > Uh-huh, so there you have it. These must be leftovers from some > > pre-extension incarnation of plpython that was never cleaned up > > properly. > > I think this was broken when Marcin first dropped the language. We > should just have dropped the extension, I guess. pg_upgrade does have some code to handle plpython call handlers in function.c:get_loadable_libraries(); * Systems that install plpython before 8.1 have * plpython_call_handler() defined in the "public" schema, causing * pg_dump to dump it. However that function still references * "plpython" (no "2"), so it throws an error on restore. This code * checks for the problem function, reports affected databases to the * user and explains how to remove them. 8.1 git commit: * e0dedd0559f005d60c69c9772163e69c204bac69 * http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php * http://archives.postgresql.org/pgsql-bugs/2012-05/msg00206.php -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
В списке pgsql-general по дате отправления: