Dropping PL language retains support functions

I have a report related to pg_upgrade where the user states that
dropping a PL language retains the PL support functions, and retains the
dependency on the PL library, which causes pg_upgrade to complain. The
exact case is that the user was using plpython2u in PG 9.0, but the PG
9.1 one-click installer only supplies plpython3u.

Pg_upgrade rightly complains that the $libdir/plpython2 is missing. The
user removed their plpython2 functions, and then tried pg_upgrade again,
and they still got the report of the missing $libdir/plpython2 library.

I tested this myself on PG HEAD, and got the same results:

CREATE LANGUAGE plpython2u;
CREATE LANGUAGE

CREATE OR REPLACE FUNCTION pymax (a integer, b integer) RETURNS integer
AS
$$
if a > b:
return a
return b
$$ LANGUAGE plpython2u;
CREATE FUNCTION

DROP LANGUAGE plpython2u CASCADE;
NOTICE: drop cascades to function pymax(integer,integer)
DROP LANGUAGE

SELECT proname,probin FROM pg_proc WHERE probin LIKE '%python%';
proname | probin
--------------------------+-------------------
plpython2_call_handler | $libdir/plpython2
plpython2_inline_handler | $libdir/plpython2
plpython2_validator | $libdir/plpython2
(3 rows)

I looked at our C code, and we basically set up this dependency:

user plpython2 function
depends on
plpython2 language
depends on
plpython2_* support functions

By doing a DROP CASCADE on plpython2, you drop the user functions, but
not the support functions.

This certainly looks like a bug. Should I work on a patch?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +