On 10 Dec 2002 at 0:02, Tom Lane wrote: > Brian Fujito <[EMAIL PROTECTED]> 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/ ---------------------------(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
