Re: "dumpProcLangs(): handler procedure for language

Brian Fujito <brian(at)lightsource(dot)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?