Re: Procedural language permissions and consequences

Поиск
Список
Период
Сортировка
От Doug McNaught
Тема Re: Procedural language permissions and consequences
Дата
Msg-id m3n0zfvuee.fsf@varsoon.denali.to
обсуждение исходный текст
Ответ на Procedural language permissions and consequences  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Procedural language permissions and consequences
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:

> Furthermore, we can conveniently eliminate the problems related to finding
> all the language handlers as shared libraries.  Since all languages are
> installed by default we can just link the handlers right into the
> postmaster, for which we don't need shared libraries.  That should give a
> great boost to languages that are currently hard to build, i.e., PL/Perl
> and PL/Python.  And the build system would become a lot simpler and more
> portable.
> 
> Any comments on these points?

Just that I imagine it's quite useful, while hacking on a procedural
language, to be able to restart the postmaster and reload the library,
rather than relinking and reinstalling the postmaster binary.  So
keeping the option for PLs in shared libraries is probably a good
idea, though having the "standard" ones compiled in makes some sense.

Wouldn't a postmaster statically linked with libperl.a and libpyhon.a
be pretty big?  Would that cause problems?

-Doug
-- 
Let us cross over the river, and rest under the shade of the trees.  --T. J. Jackson, 1863


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Procedural language permissions and consequences
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: 7.1 vs. 7.2 on AIX 5L