Re: "dumpProcLangs(): handler procedure for language

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

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

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/