Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)
Дата
Msg-id 26130.989284979@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: backend dies on 7.1.1 loading large datamodel.  (Robert Hentosh <hentosh@io.com>)
Ответы Re: Paths for C functions (was Re: Re: backend dies on 7.1.1 loading large datamodel.)  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-bugs
Robert Hentosh <hentosh@io.com> writes:
>> If this were to suck in a wrong-version copy of plpgsql.so (and yes,
>> I think 7.1 vs 7.1.1 could be wrong version) then that could cause
>> failures.

> I played with this a little.  What would be the proper solution?

At the moment, the solution is to use the createlang script rather than
issuing the commands directly.

In the long run I think we should abandon the notion that full path
specifications are the preferred way to locate dynamic libraries.
It would be a lot better for portability if C function libraries could
be referred to like this:

create function pltcl_call_handler() returns opaque
    as 'pltcl' language 'C';

where the backend automatically assumes that a relative path is relative
to $PGLIB.  I'd like to see the backend adding the file extension too,
to avoid platform dependencies (".so" is not universal).  A function
definition like the above could be dumped and reloaded without fear,
whereas the existing approach is pretty much guaranteed to break
whenever you change machines or install directories.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: backend dies on 7.1.1 loading large datamodel.
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: backend dies on 7.1.1 loading large datamodel.