Re: Procedural language permissions and consequences

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Procedural language permissions and consequences
Дата
Msg-id Pine.LNX.4.30.0201161118100.730-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: Procedural language permissions and consequences  (Doug McNaught <doug@wireboard.com>)
Список pgsql-hackers
Doug McNaught writes:

> 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.

PLs work just like user-defined C functions, so the possibility to load
your own is not going anywhere.

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

I wouldn't think so.  First, if you link statically you only get the code
you actually use (more or less).  Second, even if you get most of it, code
is only loaded into memory if you actually use it.  Third, if you don't
like it you should provide the appropriate shared libraries and the linker
should use them automatically.

-- 
Peter Eisentraut   peter_e@gmx.net



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Procedural language permissions and consequences
Следующее
От: "Command Prompt, Inc."
Дата:
Сообщение: Re: tuptoaster.c must *not* use SnapshotAny