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