Thanks for your input--
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';
I'm using pg_dump (not pg_dumpall) on the specific database on which
I created the language.
I realize 7.0.3 is ancient (same with 7.1)... I just don't have the
time to deal with an upgrade quite yet. Soon enough :) In the mean
time, a stop-gap solution would definitely be appreciated.
Thank you,
Brian
On Mon, 2002-12-09 at 14:28, Tom Lane wrote:
> Brian Fujito <[EMAIL PROTECTED]> writes:
> > I'm running postgres-7.0.3 on RH7.1 using RedHat RPMs.
> > I recently added plpgsql as a language to one of my databases,
> > and now when I try to do a pg_dump, I get:
>
> > "dumpProcLangs(): handler procedure for language plpgsql not found"
>
> > If I drop the language, pg_dump works fine, but if I add it back (and
> > even if I restart postgres), I get the same error.
>
> 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.
>
> (Also, are you doing pg_dump or pg_dumpall? If the latter, maybe the
> failure is occurring in a different database than the one you are
> changing.)
>
> But having said that, 7.0.3 is ancient history ... you really are
> overdue for an upgrade. With my Red Hat fedora on, I'd say the same
> about your choice of OS version too.
>
> regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
