Thread: Multiple call handlers per language
Hello, our production database has existed for quite a few years and been dumped/restored several times for hardware or postgresql upgrades. Original version was late 7 or early 8, we're currently on 8.4.2. I noticed on our production database I have two call handlers for plpgsql and for plpython; the following query:
select
pn.nspname,
pu0.usename as nspowner,
pp.proname,
pu1.usename as proowner,
pp.prosrc,
pp.probin
from
pg_proc pp,
pg_namespace pn,
pg_user pu0,
pg_user pu1
where
pp.proname like '%call_handler%'
and pn.oid = pp.pronamespace
and pu0.usesysid = pn.nspowner
and pu1.usesysid = pp.proowner
order by pp.proname;
Produces this:select
pn.nspname,
pu0.usename as nspowner,
pp.proname,
pu1.usename as proowner,
pp.prosrc,
pp.probin
from
pg_proc pp,
pg_namespace pn,
pg_user pu0,
pg_user pu1
where
pp.proname like '%call_handler%'
and pn.oid = pp.pronamespace
and pu0.usesysid = pn.nspowner
and pu1.usesysid = pp.proowner
order by pp.proname;
nspname | nspowner | proname | proowner | prosrc | probin
------------+----------+-----------------------+----------+-----------------------+------------------
pg_catalog | postgres | plpgsql_call_handler | postgres | plpgsql_call_handler | $libdir/plpgsql
public | postgres | plpgsql_call_handler | postgres | plpgsql_call_handler | $libdir/plpgsql
pg_catalog | postgres | plpython_call_handler | postgres | plpython_call_handler | $libdir/plpython
public | postgres | plpython_call_handler | postgres | plpython_call_handler | $libdir/plpython
(4 rows)
createdb --template=template1 krbtst
createlang plpythonu krbtst
nspname | nspowner | proname | proowner | prosrc | probin
------------+----------+-----------------------+----------+-----------------------+------------------
pg_catalog | postgres | plpgsql_call_handler | postgres | plpgsql_call_handler | $libdir/plpgsql
pg_catalog | postgres | plpython_call_handler | postgres | plpython_call_handler | $libdir/plpython
(2 rows)
Should I worry about the extra rows in our production database? If so how should I go about cleaning them?
-K
Kelly Burkhart <kelly.burkhart@gmail.com> writes: > Hello, our production database has existed for quite a few years and been > dumped/restored several times for hardware or postgresql upgrades. > Original version was late 7 or early 8, we're currently on 8.4.2. I > noticed on our production database I have two call handlers for plpgsql and > for plpython; the following query: You could presumably drop the ones in the public schema. Probably those are leftover from ancient history when these things were not getting created in pg_catalog. > Should I worry about the extra rows in our production database? If so how > should I go about cleaning them? DROP FUNCTION (as a superuser) would be the safest route. I'm pretty sure the dependency system would prevent you from dropping the wrong ones (the ones the language definitions are actually using); though you might want to verify that in a scratch copy before you do it in the production database. regards, tom lane