Tom Lane wrote: > Bruce Momjian <br...@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.
I am confused how it got defined that way? Who would be defining their own plpgsql handler? I am concerned there is some packaging that is impoperly defining it. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
