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 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 en
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
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 loadin
