Re: plpgsql.dll path - Mailing list pgsql-cygwin

From Barry Pederson
Subject Re: plpgsql.dll path
Date
Msg-id 3CDE8031.9080703@barryp.org
Whole thread Raw
In response to plpgsql.dll path  ("Felipe Nievinski" <fnievinski2@terra.com.br>)
Responses Re: plpgsql.dll path
List pgsql-cygwin
Jason Tishler wrote:
>
> Hence, the path to plpgsql.dll is *not* burned into pg_restore.exe.  Is
> it in geosist-maio09.dmp?  Or, is this kind of info stored in some other
> PostgreSQL file?
>
> Can someone knowledgeable is this area please confirm or refute the
> above?

The path to a dll for a procedural language is stored in the database.  If you
pg_dump the schema, you'll see it in there, like:

-------------------------------------
--
-- TOC Entry ID 9 (OID 22011682)
--
-- Name: "plpgsql_call_handler" () Type: FUNCTION Owner: barryp
--

CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'/usr/lib/plpgsql.dll', 'plpgsql_call_handler' LANGUAGE 'C';

--
-- TOC Entry ID 10 (OID 22011683)
--
-- Name: plpgsql Type: PROCEDURAL LANGUAGE Owner:
--

CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER "plpgsql_call_handler"
LANCOMPILER 'PL/pgSQL';
--------------------------------------

The path to the libraries does seem to have changed between 7.1 and 7.2 - and
it's not a cygwin thing, the same deal happened to me on a FreeBSD box.

There are at least two ways you can work around this (I've done both)

1) setup a symlink from the old path to the new path:

    ln -s /usr/lib/postgresql/plpgsql.dll /usr/lib/plpgsql.dll

2) dump the schema, fix the path, create a new db, load the fixed schema, and
the restore just the data.

The first solution is easiest, by you have to be sure to keep that symlink
there.  The second is harder, but fixes it permanently (or at least until the
next time they change the path).

    Barry


pgsql-cygwin by date:

Previous
From: "David P. Caldwell"
Date:
Subject: Re: rename() vs. link(); building from source
Next
From: Barry Pederson
Date:
Subject: Re: rename() vs. link(); building from source