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

From Peter Eisentraut
Subject Re: Procedural language permissions and consequences
Date
Msg-id Pine.LNX.4.30.0201161118100.730-100000@peter.localdomain
Whole thread Raw
In response to Re: Procedural language permissions and consequences  (Doug McNaught <doug@wireboard.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Procedural language permissions and consequences
Next
From: "Command Prompt, Inc."
Date:
Subject: Re: tuptoaster.c must *not* use SnapshotAny