Re: "dumpProcLangs(): handler procedure for language

On 10 Dec 2002 at 0:02, Tom Lane wrote:

> 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?

Followed by another wild guess. Could the path be the problem?
Looking at my notes (http://www.freebsddiary.org/postgresql-
pgsql.php) I see that at one time I supplied a pathname :

CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
'/usr/local/pgsql/lib/plpgsql.so' LANGUAGE 'C';

Please let us know.
--
Dan Langille : http://www.langille.org/