Re: Procedural language permissions and consequences - Mailing list pgsql-hackers

From Doug McNaught
Subject Re: Procedural language permissions and consequences
Date
Msg-id m3n0zfvuee.fsf@varsoon.denali.to
Whole thread Raw
In response to Procedural language permissions and consequences  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Procedural language permissions and consequences  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Procedural language permissions and consequences
Next
From: Bruce Momjian
Date:
Subject: Re: 7.1 vs. 7.2 on AIX 5L