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 по дате отправления: