Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers

Bruce Momjian <bruce@momjian.us> writes:
> David Platt wrote:
>> The following definition is my database:
>>
>> CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler
>> LANGUAGE c
>> AS '/opt/postgres/8.4.1/lib/plpgsql', 'plpgsql_call_handler';
>>
>> The file /opt/postgres/9.rc1/lib/plpgsql.o exists but the pg_upgrade run
>> fails on an error loading /opt/postgres/8.4.1/lib/plpgsql.o.

> What is the error?  What old version of PG are you migrating from?

Well, it's obviously going to fail, because it will try to load an 8.4
version of plpgsql.so into 9.0.  The same would happen if you tried to
pg_dump and reload --- it's by no means the fault of pg_upgrade.

IMO this is just pilot error.  The call handler should never have been
declared like that, precisely because the definition will not port to
other releases or even other installation locations.  The right way for
the definition to look like is

    ... AS '$libdir/plpgsql'

or perhaps even just

    ... AS 'plpgsql'

if you'd like to rely on the dynamic_library_path setting.

I suspect David thinks that pg_upgrade should try to edit the library
path name, but IMO that would be seriously dangerous, as well as not
necessary if reasonable practices have been followed.

            regards, tom lane