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
