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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers