Обсуждение: 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