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:
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)
When I run this on a fresh database created on a fresh cluster like this:
createdb --template=template1 krbtst
createlang plpythonu krbtst
I see this:
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
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general