Re: BUG #16178: DROP LANGUAGE plpythonu; doesn't actually drop language.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: indreek(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16178: DROP LANGUAGE plpythonu; doesn't actually drop language.
Date: 2019-12-23 13:46:33
Message-ID: 18081.1577108793@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> [ assorted manual manipulation of plpythonu language ]

> Doing the same thing with extensions works fine.

This is in the category of "if it breaks you get to keep both pieces".
We don't really support installing PLs via any other means except their
extensions anymore.

In the case at hand, I believe what's biting you is that CREATE LANGUAGE
auto-created the language's support functions (because the alternative
would be to fail entirely) but DROP LANGUAGE didn't drop them. Nobody
is going to work on changing that. The actual likely future direction
of development is for the auto-creation behavior to go away [1], so
there would hardly be any point in hacking up DROP LANGUAGE.

I'd suggest manually dropping the support functions
(plpython_call_handler, plpython_inline_handler, plpython_validator)
to get back to an upgradable state. Or you could install plpython2
in the new installation.

regards, tom lane

[1] https://www.postgresql.org/message-id/flat/5889.1566415762%40sss.pgh.pa.us

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-23 14:36:38 Re: BUG #16177: pg_event_trigger_ddl_commands() returns empty set for ddl_command_start and "drop table"
Previous Message Sandeep Thakkar 2019-12-23 12:56:32 Re: PostgreSQL\12\bin\pg_ctl.exe - Trojan detected