> On Nov 18, 2020, at 9:29 PM, Bruce Momjian <bruce@momjian.us> 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@momjian.us> 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.
>