GMX LINREG <linreg@gmx.net> writes:
> output from source database:
> botdb=# \dx+ plperlu
> Objekte in Erweiterung »plperlu«
> Objektbeschreibung
> --------------------
> language plperlu
Yeah, that's definitely broken: it should look like
\dx+ plperlu
Objects in extension "plperlu"
Object description
-------------------------------------------
function plperlu_call_handler()
function plperlu_inline_handler(internal)
function plperlu_validator(oid)
language plperlu
(4 rows)
Offhand I think that completely explains pg_dump's failure: it relies on
the dependency-membership entries to decide that it ought to dump the
language support functions, so if they're not there, this is what you get.
It's possible that the entries *are* there but they're not being found due
to index corruption. You could try "REINDEX TABLE pg_depend" and see if
the \dx+ output changes. I don't have a lot of hope for that though.
The next easiest fix would be to see if you have any plperlu functions
to worry about, and if not, just drop the busted extension.
If you do have some such functions, the best bet might be to dump
them separately, go ahead and DROP CASCADE the busted extension,
then upgrade; and restore the plperlu functions separately afterwards.
It'd be kind of interesting to figure out why those pg_depend entries
are missing, but I suppose the evidence is long gone :-(
regards, tom lane