Re: 7.1->7.2 data import timestamp problems - Mailing list pgsql-admin

From Tom Lane
Subject Re: 7.1->7.2 data import timestamp problems
Date
Msg-id 26783.1014498366@sss.pgh.pa.us
Whole thread Raw
In response to Re: 7.1->7.2 data import timestamp problems  (Sean Chittenden <sean@chittenden.org>)
Responses Re: 7.1->7.2 data import timestamp problems  ("Dan Langille" <dan@langille.org>)
List pgsql-admin
>> [1] - the change I made: this
>>
>> CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
>> '/usr/local/lib/plpgsql.so', 'plpgsql_call_handler' LANGUAGE 'C';
>>
>> became
>>
>> CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
>> '/usr/local/lib/postgresql/plpgsql.so', 'plpgsql_call_handler'
>> LANGUAGE 'C';
>>
>> which is the default location under the latest FreeBSD port.

> I've run into this a few times and have talked with the maintainer and
> think that a note regarding this change may come in future versions of
> the pgsql port.

Actually, under 7.2 the preferred definition is just

CREATE FUNCTION "plpgsql_call_handler" () RETURNS opaque AS
'plpgsql', 'plpgsql_call_handler' LANGUAGE 'C';

It's no longer necessary to supply a full path to the shlib, and
in fact it's best to let the shlib loader fill in the default path.
That should prevent future occurrences of this sort of problem.
Almost certainly, the reason you got burnt to begin with was that
the dumped definition of plpgsql_call_handler contained the full
path to the *old* installation's plpgsql.so --- am I not right?
We got smart about that at last, and now there is a search path
for shlibs in the loader code.  But it won't help you unless you
use it.

> Are there any plans to merge in the Heimdal kerberos patches?  -sc

Peter said he committed it yesterday...

            regards, tom lane

pgsql-admin by date:

Previous
From: "Dan Langille"
Date:
Subject: Re: 7.1->7.2 data import timestamp problems
Next
From: "Dan Langille"
Date:
Subject: Re: 7.1->7.2 data import timestamp problems