Re: 7.1->7.2 data import timestamp problems

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 7.1->7.2 data import timestamp problems
Дата
Msg-id 26783.1014498366@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 7.1->7.2 data import timestamp problems  (Sean Chittenden <sean@chittenden.org>)
Ответы Re: 7.1->7.2 data import timestamp problems  ("Dan Langille" <dan@langille.org>)
Список 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 по дате отправления:

Предыдущее
От: "Dan Langille"
Дата:
Сообщение: Re: 7.1->7.2 data import timestamp problems
Следующее
От: "Dan Langille"
Дата:
Сообщение: Re: 7.1->7.2 data import timestamp problems