Re: "dumpProcLangs(): handler procedure for language

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?