Brian Fujito <brian@lightsource.com> writes:
>> What exactly are you doing to drop and re-add the language? I should
>> think CREATE LANGUAGE would fail if the handler proc isn't there.
> I've tried both ways:
> createlang/droplang from the command line as user postgres
> and:
> CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
> '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';
> CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql'
> HANDLER plpgsql_call_handler
> LANCOMPILER 'PL/pgSQL';
Hrmph. Looks perfectly standard from here; I don't see why pg_dump is
failing to find the handler. It would help to see what the server-side
view of the transaction is like. Would you run pg_dump after setting
query logging on (from memory, I think export PGOPTIONS="-d2" will work
in 7.0, but too tired to check it) and then show us the tail end of the
postmaster log after pg_dump fails?
regards, tom lane
PS: a wild-*ss guess: 7.0 wasn't too clean in handling OIDs above 2
billion; is it possible your pg_language OID for plpgsql is over 2G?
