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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #16178: DROP LANGUAGE plpythonu; doesn't actually drop language.
Дата
Msg-id 18081.1577108793@sss.pgh.pa.us
обсуждение исходный текст
Ответ на BUG #16178: DROP LANGUAGE plpythonu; doesn't actually drop language.  (PG Bug reporting form <noreply@postgresql.org>)
Список pgsql-bugs
PG Bug reporting form <noreply@postgresql.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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Sandeep Thakkar
Дата:
Сообщение: Re: PostgreSQL\12\bin\pg_ctl.exe - Trojan detected
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: BUG #16177: pg_event_trigger_ddl_commands() returns empty setfor ddl_command_start and "drop table"