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 integerAS     $$         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 onplpython2 language    depends onplpython2_* 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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +