I first tried to take care of the problem by removing -L $libpath
from the arg list passed to createlang. This worked in a way that
probin in pg_proc had value $libdir/plpgsql.
Later it turned out the embedded library path was used, and install
failed when there was no access to the build
Sorry, I forgot to mention that I also considered bypassing createlang
and using direct sql:
... RETURNS LANGUAGE_HANDLER AS '${pglib}/plpgsql' ...
but I'm not sure if this is much better then updating pg_proc.
-
I first tried to take care of the problem by removing -L $libpath
I'm running Postgres v.7.3.4.
In my database dump file I see this:
CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
AS '/home/tmichael/build/relipg21/syncinc/lib.sol2/plpgsql',
'plpgsql_call_handler'
LANGUAGE c;
The hardcoded library path may become an obstacle when
Michael Brusser [EMAIL PROTECTED] writes:
I'm running Postgres v.7.3.4.
In my database dump file I see this:
CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
AS '/home/tmichael/build/relipg21/syncinc/lib.sol2/plpgsql',
'plpgsql_call_handler'
LANGUAGE c;
The
