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. +
