Multiple call handlers per language

Started by Kelly Burkhartover 11 years ago2 messagesgeneral
Jump to latest
#1Kelly Burkhart
kelly.burkhart@gmail.com

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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Kelly Burkhart (#1)
Re: Multiple call handlers per language

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