Laurent FAILLIE <l_faillie@yahoo.com> writes:
> scheduling=# select * from pg_proc where
> proname='plpgsql_call_handler';
> proname | proowner | prolang | proisinh
> | proistrusted | proiscachable | proisstrict |
> pronargs | proretset | prorettype | proargtypes |
> probyte_pct | pro
> perbyte_cpu | propercall_cpu | prooutin_ratio |
> prosrc | probin
>
----------------------+----------+---------+----------+--------------+---------------+-------------+----------+-----------+------------+-------------+-------------+----
> ------------+----------------+----------------+----------------------+---------------------------------
> plpgsql_call_handler | 1 | 13 | f
> | t | f | f |
> 0 | f | 0 | | 100
> |
> 0 | 0 | 100 |
> plpgsql_call_handler | /usr/local/pgsql/lib/plpgsql.sl
Well, that looks reasonable, but what's its OID? (should've asked for
select oid,* from ...)
The easiest way to get back to a working database is to UPDATE the
pg_language row with the correct OID of the call handler function.
I'd be interested to know how you got into this state, though.
I have to think that you dropped and recreated the handler function
without going through the full 'droplang'/'createlang' cycle.
regards, tom lane
