> On Nov 18, 2020, at 9:29 PM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: > > 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@xxxxxxxxxx> https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > > Unless it stop at prompts for “Yes, ok, I understand.” this could easily fly out the window. >
